This is the mail archive of the mailing list for the GCC 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: Link problems with section anchors

Alan Modra <> writes:
> On Fri, Aug 04, 2006 at 10:11:42AM -0400, David Edelsohn wrote:
>> >>>>> Richard Sandiford writes:
>> Richard> Ick.  I really have to question whether that's valid.  GCC does care
>> Richard> whether something is link-once or not -- as this PR proves -- so changing
>> Richard> it behind GCC's back seems like a very bad idea.
> Err, it's hardly behind GCC's back.  The .gnu.linkonce is there quite
> plainly in the attribute, and expecting GCC to notice the special
> section isn't unreasonable.

Well, I disagree. ;)

>> 	Yes, as is being discussed on #gcc, changing sections with GCC
>> __attribute__ is fine, but this code is changing section semantics behind
>> the compiler's back.  One simply cannot expect that to work.  Linkonce
>> sections are not just a blackbox string value for GCC to emit.
> Well, yes, currently GCC itself only sets DECL_ONE_ONLY due to C++
> language constructs.  Is there some reason why we can't notice
> ".gnu.linkonce." in a section attribute and set the flag as in the
> following patch?  I'll note that other parts of GCC act on certain
> section names set via an attribute.  eg. see rs60000_elf_in_small_data_p
> where ".sdata", ".sbss" and other similar section names are tested.

Yes, but as David says, changing _sections_ with the section attribute
is fine.  Our position is that changing program semantics isn't.
And that's the difference between .sdata and .gnu.linkonce.
The former doesn't change program semantics but the latter does.

Or to put it another way, recognising ".sdata" is just an optimisation.
Nothing bad should happen if gcc fails to recognise a nonstandard
section name that the user has chosen to place in the GP range.
But bad things _do_ happen if gcc fails to treat something as link-once
that actually is link-once.

I really think recognising ".gnu.linkonce" as a magic string is a bad
idea.  There was talk on #gcc at the time about adding a new attribute
specifically for making something link-once.  I still think that's the
right way to go.


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