This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: COMDAT group names become anonymouse local symbols


On Tue, Oct 19, 2010 at 01:08:38PM -0700, Mark Mitchell wrote:
> 
> When assembling this trivial file:
> 
> 	.section	A,"axG",%progbits,B,comdat
>         # Note that there is no definition of the symbol B.     		
> 
> GAS generates a COMDAT group whose "signature" (in the sense of the
> ELF spec) is an anonymous local symbol:
> 
> Section Headers:
>   [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
>   [ 1] B                 GROUP           0000000000000000 000040 000008 04      7   5  4
> 
> Symbol table '.symtab' contains 6 entries:
>    Num:    Value          Size Type    Bind   Vis      Ndx Name
>      5: 0000000000000000     0 SECTION LOCAL  DEFAULT    1 
> 
> This seems bad.  The documentation for the .section directive says
> that B is the group name, and since the linker's collapsing of COMDAT
> groups is done based on the *signature*, not the name referred to by
> the section header itself, this seems wrong.

I don't see anything bad about this (except possibly if you are using
a linker other than GNU ld or gold).  That isn't an "anonymous" local
symbol.  That is the section symbol for the group section named "B".
GNU ld saves .strtab space by leaving st_name zero on section symbols;
The name of such a symbol is given by the section sh_name.  So the
group signature is indeed "B".

In cases like this, where a non-section symbol having the same name a
the group signature does not already exist, gas could create a normal
local symbol just for the group name.  You'd then get the group name
in .strtab *and* you'd have ".group" in .shstrtab.  With the current
gas fallback, you just have the group name in .shstrtab.  I'll grant
that is not much of a saving, but when I first wrote the gas group
support, gas always named the group section with the name of the group
signature.  It seemed reasonable to leave that as a fallback when a
non-section symbol with the group name does not exist.

> On the other hand, perhaps GCC shouldn't generate code like this.  (It
> does, at present, for certain C++ inputs.)  The assembler certainly
> shouldn't create a global symbol named "B".  If the assembler were to
> create a local symbol with the name "B", would the linker still
> combine this COMDAT group with another group in another object file
> also named "B", even if both had different local symbols as their
> signatures?

Yes.

-- 
Alan Modra
Australia Development Lab, IBM


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]