This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] ld: Allow section groups to be resolved as part of a relocatable link
- From: Andrew Burgess <andrew dot burgess at embecosm dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: binutils at sourceware dot org
- Date: Thu, 13 Apr 2017 23:07:13 +0100
- Subject: Re: [PATCH] ld: Allow section groups to be resolved as part of a relocatable link
- Authentication-results: sourceware.org; auth=none
- References: <1490368289-27049-1-git-send-email-andrew.burgess@embecosm.com> <20170404100120.GE16711@bubble.grove.modra.org>
* Alan Modra <amodra@gmail.com> [2017-04-04 19:31:21 +0930]:
> On Fri, Mar 24, 2017 at 03:11:29PM +0000, Andrew Burgess wrote:
> > This commit adds a new linker feature: the ability to resolve section
> > groups as part of a relocatable link.
>
> What happens with dwarf debug or .eh_frame info for discarded
> sections?
Alan,
Thanks for the feedback, sorry for the slow reply.
I wasn't totally sure what you're asking for, as far as I'm aware
debug and eh_frame sections will work largely as before. However,
given your question I suspect you've spotted something that I'm still
not getting.
Below I've written down how I _think_ things work. I'm guessing that
there's more complexity in some aspect that I'm missing (and that
you've spotted).
Currently, if we do a relocatable link of object_a and object_b into
object_ab, then fully link this into exe_ab I believe that we expect
the following to happen:
1. object_a and object_b contain section groups for some .text*
sections.
2. object_a and object_b contain .debug* that reference symbols in
.text* sections, some these sections will be in section groups, and
some will not.
3. During the partial link we merge the section groups, discarding
all but one copy of each. References to symbols in discarded
sections are updated to reference the symbols in the kept copy.
4. During the final link the section group is discarded, and the
members become "regular" sections, to be placed in the normal way.
Symbol references in the .debug* are resolved to the single copy of
each symbol we now have.
If the new feature I propose is not used (by the user) then I expect
nothing to change.
If the user requests that groups be resolve at partial link time then
I expect:
1. As above.
2. As above.
3. During partial link we discard all section groups, and all but
one copy of each member of the section groups. The one remaining
section group members become "regular" sections and are placed in
the normal way. References to symbols in the discarded section
groups are updated to reference the symbols in the kept sections.
4. During the final link there are now no section groups. All
sections are placed in the normal way and relocations are patched as
normal.
If the user requests that groups NOT be resolved during the final link
then I expect to see this behaviour:
1. As above.
2. As above.
3. Back to the original behaviour; During the partial link we merge
the section groups, discarding all but one copy of each. References
to symbols in discarded sections are updated to reference the
symbols in the kept copy.
4. During final link section groups are merged. All but one copy of
each of the group members is discarded, references to symbols in
discarded sections are updated to reference the symbols in the kept
copy. The group members will most likely be placed as orphan
sections with the linker picking a location for the section to
live. As this is a final like relocations in the debug* sections
will be resolved in the normal way.
I'd expect eh_frame sections to be handled in exactly the same way.
Any guidance you could offer would be gratefully received.
Thanks,
Andrew