Re: Feature request: .section$key

[Jason Merrill <jason at redhat dot com>]

>>>>> Geoff Keating <geoffk@cygnus.com> writes:

 > From what I can see of the proposal, it looks like it's just a
 > convenience for people writing linker scripts.

Rather, it's a convenience for people wanting this functionality for
new sections.  If I want to get this functionality for, say, .debug_info,
it would be nice not to have to go through and add the standard boilerplate
to all linker scripts.

I like general features better than conventions that require a great deal
of coordination and make-work.  History shows that if we require linker
script support for features to work, they break on half the embedded
targets.

>>>>> Ulrich Drepper <drepper@redhat.com> writes:

 > Jason Merrill <jason@redhat.com> writes:
 >>  > What is it exactly you want to achieve with this?  If this is done
 >>  > only at link time the only difference to the current behavior is that
 >>  > the binary will not contain the information about the sections which
 >>  > is a bit more compact.
 >> 
 >> For, say, .ctors and .debug_info, it is required for correctness.

 > Sorry, I still don't see what you mean.

All DWARF debugging info must go in .debug_info.  I want to split it up, do
comdat elimination, and combine it again.  If it isn't combined again, the
debugger has no way of knowing about the info in the other sections.

 > Grouping is important in relocatable files so that sections get used or
 > discarded tobether (we just had this discussions with the
 > --gc-sections).  This is addressed in the new ELF gABI by introducing
 > section groups.

Yep.  Section groups would accomplish the same goal, so long as there is
assembler support for multiple sections with the same name.  It's more
complex, but would also serve my purposes.

 > But you were talking about the linker.  In the final binary there is
 > not much of a difference whether code is in one section or multiple
 > sections.

See above.  Besides, we already combine the various text sections; someone
apparently felt that it made sense to do so.

 >> I wouldn't object to turning the linkonce property into an ELF flag (or
 >> just implementing the COMDAT groups feature), but when the key you want to
 >> control section matching is already a symbol name, it makes sense to put it
 >> in the section name.

 > We don't want the section name to be a key.  This is wrong, it is
 > dangerous.  Information about the content of a section must be
 > explicit and not implied by some magic name.

I meant, a key for comparison.  The section name is already a key; .text is
combined with .text, and not with .data.  If we want to create a separate
text section for bob, we currently call it .text.bob, and all .text.bob
sections are considered together.  That's what I mean by 'key'.

Jason