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: Tue, 9 May 2017 18:29:42 +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> <20170413220713.GH28064@embecosm.com>
Alan,
Any followup to the below?
Thanks,
Andrew
* Andrew Burgess <andrew.burgess@embecosm.com> [2017-04-13 23:07:13 +0100]:
> * 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