> As one of the strong advocates for the fix that was made to make
> protected visibility work correctly with data symbols, I'd like to
> explain why it was the right decision and why it matters. This whole
> process is really frustrating to me -- having invested a lot of effort
> into getting some
> Another old bug:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10908
Filed by you, and resolved (correctly) as invalid. Again, the real
problem was the lack of a linker diagnostic.
-cary
> Cary, please stop spreading the incorrect information. There is
> at lease one GCC bug against protected symbol:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55012
>
> which was reported by other people.
OK, so it got reported once by someone else. But that bug was based on
an incorrect un
>> So with all this it sounds that current protected visibility is just
>> broken and we should forgo with it, making it equal to default
>> visibility?
>
> Like how? You mean in GCC regarding protected as default visibility? No,
> that's just throwing out the baby with the water. We should make
>> That is why protected visibility is such a mess.
>
> Not mess, but it comes with certain limitations. And that's okay. It's
> intended as an optimization, and it should do that optimization if
> requested, and error out if it can't be done for whatever reason.
I completely agree.
> E.g. one
>> Given a shared library that defines a variable, and a non-PIC
>> executable that references that variable, the linker makes a duplicate
>> of the variable in the executable .dynbss section and arranges to have
>> the copy initialized by the dynamic loader with a copy relocation.
>> .dynbss is a
We're in the final stages of finalizing the DWARF v5 spec, which will
include the Fission extensions. When that's done, we'll start
converting GCC and gold over to use the official DWARF features rather
than the GNU extensions.
>> + The "Fission" project was started in response to the problems cau
> include/plugin-api.h defines an ABI between linker and compiler,
> which can be used to implement linker plug-in by any compilers.
> I'd like to add GCC Runtime Library Exception to include/plugin-api.h
> so that the linker plug-in can have non-GPL licenses.
This is OK with me.
-cary
> 3.3.2 Static Linking Object Acceptance Rules
>
> The static linker shall follow the user selection as to the linking mode
> used, either of `strict' and `relaxed'. The selection will be made
> according to the usual way assumed for the environment used, which may be
> a command-line option, a p
> Does static pie (ET_DYN with non-fixed load address, _DYNAMIC
> relocations, but no PT_INTERP, DT_NEEDEDs, or symbolic relocations)
> currently work with gold? If so, what is the way to request it? I
> would say it would make sense to try to do things the same, but from
> what you're saying it so
> This is OK to commit with a suitable ChangeLog. I think a separate ld
> option is best too, because historically -static and its aliases
> -Bstatic, -dn, -non_shared really are about what type of libraries are
> accepted rather than choosing linker output type.
Gold actually separates these con
> So far, I've been prototyping static PIE support by having GCC pass
> the following options to ld instead of -static -pie:
>
> -static -shared -Bsymbolic
>
> This partly works, but since ld does not know it's producing a main
> executable, it misses important details, including the abilit
>> Normally, the version identifier is applied to a type. It then
>> propagates to any declaration using that type, whether it's another
>> type or function or variable. For struct/union/class types, if any
>> member or base class has an attached version identifier (excluding
>> static data members
>> Next, I compiled a 5000-line C++ source file at both -O0 and -O2.
>
> I have to assume that David is working with C code, as stabs debugging
> for C++ is nearly unusable.
I assumed that too, but I figured C++ would be worse than C as far as
DWARF vs. stabs size. I'd still be interested to figur
>> If I use objcopy --compress-debug-sections to compress the DWARF debug
>> info (but don't use it on the STABS debug info), then the file size
>> ratio is 3.4.
>>
>> While 3.4 is certainly better than 11.5, unless I can come up with a
>> solution where the ratio is less than 2, I'm not currently
> We had a useful discussion about C++11 ABI issues at the GNU Tools
> Cauldron (http://gcc.gnu.org/wiki/cauldron2012). The approach will be
> shaped over time, but the general idea is as follows.
>
> We will modify g++ to support a type attribute indicating the version
> of the type, as a string.
> To do this, I would like to reserve a bit in the segment flags to
> indicate that this segment is to be mapped to huge pages if possible.
> Can I reserve something like a PF_LARGE_PAGE bit?
HP-UX has a PF_HP_PAGE_SIZE (0x0010) bit that says "Segment should
be mapped with page size specifie
string & list changes
- function w/ string arg
- classes w/ string members
- global variables
- link c++98 & c++0x together
- link existing c++98 .o & new c++-x .o
- link at runtime c++98 .so & new c++0x .so
HP: attribute on type propagates to:
- function (params or return type)
- structs w/ mem
> But I am still missing something, why is the performance so different?
> Code layout putting the constructors' body in the reverse order they
> are called?
Yes, as I understand it. Cache and TLB prefetching works better when
code executes from lower to higher addresses than when executing from
h
>> Furthermore, if you're working in chromium, you should be aware that
>> the new behavior is exactly what the Chrome developers are arguing
>> for, as it makes the startup faster. It sounds to me like you're
>> working at cross purposes with the other developers on that project.
>
> Ah, perhaps t
> So this is not as bad as I was expecting (old programs still work),
> but it is still a somewhat annoying ABI change to handle. I think we
> can add support for this in clang in 3 ways:
>
> 1) Require new linkers when using gcc 4.7 libraries.
> 2) Ship our own versions of crtbeginS.o (and similar
> We only have very few bits to in STB_XXX field.
This is exactly why I'm not in favor of this extension. The feature
doesn't seem compelling enough to use up one of these precious
reserved values (in fact, you're using the next-to-last one that's
reserved for OS use).
You want a backup definitio
> This seems clearly wrong to me. A reference to a symbol in a discarded
> section should not resolve to an offset into a different section. I thought
> the linker always resolved such references to 0, and I think that is what we
> want.
Even resolving to 0 can cause problems. In the Gnu linker,
> Yeah, but it’s a shame that those compilers define __GNUC__ without
> supporting 100% of the GNU C extensions. With this approach, you would
> also need to add !defined for Clang, PGI, and probably others.
Having worked on the other side for a while -- for a vendor whose
compiler supported many
>> Is there a way to detect that basic blocks have the same range even
>> though they have different block numbers? Or am I not looking/thinking
>> about this issue correctly?
I may be oversimplifying this, but it seems that
gen_inlined_subroutine_die generates a DW_AT_ranges list, then calls
decl
I'd like to create a new "fission" branch on the GIT mirror at
ssh://gcc.gnu.org/git/gcc.git. This branch will host the changes that
Sterling and I will be making to support splitting the debug info into
separate files -- and, as a byproduct, fixing the pubnames and
pubtypes tables so they can be u
> The Apple approach has both the features of the Sun/HP implementation as well
> as the ability to create a standalone debug info file.
Thanks for the clarifications. I based my comments on a description
you sent me a couple of years ago, and I apologize for any
oversimplifications I introduced.
>> * .debug_pubtypes - Public types for use in building the
>> .gdb_index section at link time. This section will have an
>> extended format to allow it to represent both types in the
>> .debug_dwo_info section and type units in .debug_types.
> ^^^
> = .dwo_info , maybe both
At Google, we've found that the cost of linking applications with
debug info is much too high. A large C++ application that might be,
say, 200MB without debug info, is somewhere around 1GB with debug
info, and the total size of the object files that we send to the
linker is around 5GB (and that's w
> This brings out 2 questions. Why don't GCC 4.4/4.6/4.7 warn it?
> Why doesn't 64bit GCC 4.2 warn it?
Good question. It seems that the difference is whether the compiler
generates a field-by-field copy or a call to memcpy(). According to
David, the trunk gcc in 32-bit mode doesn't call memcpy, b
> I saw that dwarf2out.c (generate_type_signature) does not just calculate
> the complete type signature for use with DW_AT_signature, but also
> outputs a DW_AT_GNU_odr_signature. The comment says:
>
> /* First, compute a signature for just the type name (and its
> surrounding context, if any.
>> I'm not sure if with your patch the add_input_library or
>> add_input_file plugin hooks are completely useless (and thus
>> gold could simply ignore those at all).
>
> The plugin does need to use the add_input_file callback. In any case
> I'm not sure it's a great idea for gold to ignore a hook
> Here is an alternative proposal, with a patch for gold.
>
> We add a new plugin vector: LDPT_REGISTER_RESCAN_ARCHIVE_HOOK. Like
> LDPT_REGISTER_CLAIM_FILE_HOOK, this gives the plugin the address of a
> function which can register a plugin function: rescan_archive.
>
> typedef
> enum ld_plugin_st
> Here is my proposal. Any comments?
We talked about ld -r a while back during the WHOPR project, and the
two ways that the linker could work: (1) combine all the .o files and
use the plugin to run LTRANS on the IR files, producing a pure,
optimized, object file; and (2) combine the non-IR object
>>> I see no particular reason why that should be the case. The issues are
>>> conceptually simple.
>>
>> I'd like to a gold implementation which works on all known cases.
You'd like to what?
> BTW, gold LTO plugin miscompiled 416.gamess in SPEC CPU 2006:
>
> http://www.sourceware.org/bugzilla/s
>>> Another way to do this would be to put a marker in the command line
>>> that identifies where those libraries begin, and the linker could just
>>> go back and rescan those libraries if needed, before the final layout
>>> of the endcaps.
>>
>> I like that idea in general, but the difficulty is k
> For the crtend files we could add a linker option that makes them
> known as endcaps, and the linker could make sure they get laid out
> last:
>
> ld ... -lc -lgcc ... --endcap crtend.o crtn.o
>
> That puts the special knowledge about those files back in the gcc driver.
I should have remembere
>> I wouldn't expect the compiler to introduce a call to anything in libm
>> when -lm isn't already specified on the command line (that would break
>> even without LTO).
>
> Right--that would break without LTO, but it doesn't follow that we
> should make it work with LTO.
That's my point, too.
>>
> This isn't quite what should happen, though. If the user does not
> specify -lm on the link line, then we should not add -lm, even if LTO
> somehow introduces a function that is defined in libm. Automatically
> adding -lm would introduce a surprising dynamic dependency in some
> cases. The use
>> For the crtend files we could add a linker option that makes them
>> known as endcaps, and the linker could make sure they get laid out
>> last:
>>
>> ld ... -lc -lgcc ... --endcap crtend.o crtn.o
>>
>> That puts the special knowledge about those files back in the gcc driver.
>
> Hmm, yes.
> For each libcall, we need to decorate
>
> 1. Which library it comes from. It is OS/target dependent.
> 2. The dynamic and static library names. In most cases, they
> are the same. For glibc, they are different.
Is there a relatively painless way to enumerate all the possible
libcalls? We coul
> I propose that we add a new linker option: --plugin-callback. At each
> point where this option appears on the command line, the linker will
> call a new plugin callback entry point. The LTO plugin will replace the
> all_symbols_read callback with this one. We will have the gcc driver
> run th
> I'm wondering if the linker shouldn't just gather the plugin-contributed
> object files, substitute them into appropriate places on the original
> command-line, and re-exec itself.
That's not effectively different from the collect2 approach that we
had before the linker plugin interface. The on
>> I'm also not sure what you mean by "resolved IRONLY except that it is
>> externally visible to the dynamic linker." If we're building a shared
>> library, and the symbol is exported, it's not going to be IRONLY, and
>> I don't see how it would be valid to optimize it out. If we're
>
> Well, the
>> The only aspect of link
>> order that isn't maintained is the physical order of the sections in
>> memory.
>
> That is exactly the problem my proposal tries to address.
Really? That's not at all what PR 12248 is about. The physical order
of the sections (meaning the order of contributions withi
>> That is what "Discard all previous inputs" in stage 2 linking is for.
>
> But what does that mean? Are you saying that the linker interface to
> the plugin should change to work that way? If we do that, then we
> should change other aspects of the plugin interface as well. It could
> probably
> If we get into extending linker plugin interface, it would be great if we
> would
> do somehting about COMDAT. We now have RESOLVED and RESOLVED_IRONLY, while
> the
> problem is that all non-hidden COMDAT symbols get RESOLVED that pretty much
> fixes them in the output library.
>
> I would pro
> But if I understand correctly, mixed LTO/non-LTO + whole-program is
> almost never correct. So we should really emit a warning for this
> specific combination. I think making this mistake would be quite easy
> but hard to debug.
It's not only correct, it's essential. "Whole Program" doesn't mean
>> Yes, this is also what I saw without plugin. I just wonder why "v"
>> is linked with plugin if resolution file is not used to eliminate need
>> of externally_visible attribute here.
>
> Probably because of the same linker-plugin bug that causes bar
> to be resolved.
Just to make sure I unde
> extensibility, this isn't a problem for these extensions, as older
> DWARF readers will simply ignore the location expressions that use the
> extensions -- which produces the same behavior as DWARF-2 without
> those extensions.
I said "will simply ignore" when I guess I should have said "should
> Are you saying that current gcc trunk should require -gdwarf-4
> to issue dwarf4 commands? I ask because r151815...
>
> http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00220.html
>
> causes dwarf4 by default. Is there a consistent policy on this?
> Currently in PR41405, there is a proposal for a -
>> So aren't we now likely to lose the first few days of what little remains
>> of
>> stage 1 waiting for trunk to start working again, then have a mad rush of
>> people falling all over each other to get their new features in in the last
>> couple of days? One of which will inevitably break tr
(This question probably should be on gcc-help instead of this list.)
> I'm trying to redirect I/O in my C++ application and am having some
> difficulty. I am trying to use cout or a file for output based on some
> condition. cout is an ostream object and file is an ofstream object.
> The types are
> With SEH you can catch that kind of errors and that's why it's so
> interesting in embedded world
That's also why SEH is a major pain for optimization. The compiler
would have to identify every instruction that may trigger an
exception, and either treat that instruction as a scheduling boundary
> However, on LTO, we may have several personality functions in the same
> object file. So, it's not clear what should we do here. Should we
> call dwarf2out_frame_finish() for each of the personalities that we
> saw in that file?
I don't think so. We're calling dwarf2out_frame_finish() at the en
LTO currently doesn't support the generation of debug info very well,
as we discard much of the front-end information that is needed for
debug info before streaming the IR to the intermediate file. I've
written up the following proposal to fix this, and have also posted it
on the gcc wiki:
http:
> This is PR 36690 which has various bits of analysis.
Thanks! I did search for this problem, but I guess I didn't use the
right terms, and it didn't turn up this bug report. Looks like if I
had done another search after analyzing the problem, it probably would
have turned up.
-cary
There are a couple of failures in the gdb test suite on i386 and
x86_64 with gcc 4.3.0 or newer. The tests gdb.base/break.exp and
gdb.base/sepdebug.exp are failing with a function begins with a while
loop. The into_cfg_layout_mode pass was added in 4.3.0 (see
http://gcc.gnu.org/ml/gcc-patches/2007-
> On the "claim file", can you also pass the "file" size in the case it
> is inside an archive?
Good idea. Will do.
-cary
> * "End of first pass" may be a little gold specific. Perhaps it
> should be called something like "after all input files have been
> seen."
Sure. It seems to me that the pass 1, middle, pass 2 breakdown is
pretty common for linkers, though perhaps not universal. I'll find a
better name (I was
> We've started working on the driver and WPA components for whopr.
> These are some of our initial thoughts and implementation strategy. I
> have linked these to the WHOPR page as well. I'm hoping we can
> discuss these at the Summit BoF, so I'm posting them now to start the
> discussion.
I've
Let me second H.J.'s suggestion to post your request at
http://groups.google.com/group/generic-abi
In the absence of any SCO presence, that group now serves as the
closest thing we have to a standards forum for ELF and the gABI.
-cary
> I think that one of the goals here is to not make that too dependent on elf.
> For instance, we are in the process of getting rid of all of the dwarf.
> After maddox does that, our only dependence on elf will be as a container
> to hold all of the sections.
> Given that gcc is not always an elf
> 2) LTO sections need to be able to find "their index" of decls and
> types. By "their index" I mean the index that each section used to
> reference the decls and types when the section was generated.
Can't you just put an ELF symbol (can be an unnamed local -- could
even just be a section sy
64 matches
Mail list logo
