This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [gold] Relocation data handling for comdat sections when doing a relocatable link
- From: Artemiy Volkov <artemiyv at acm dot org>
- To: binutils at sourceware dot org
- Cc: Cary Coutant <ccoutant at gmail dot com>
- Date: Sat, 10 Dec 2016 00:53:27 +0300
- Subject: Re: [gold] Relocation data handling for comdat sections when doing a relocatable link
- Authentication-results: sourceware.org; auth=none
- References: <CAOxjHa1_pLz838nB=KfxBF8xbYhVLd52U6GP4CO-XjL=WRvLUQ@mail.gmail.com>
- Reply-to: artemiyv at acm dot org
On Mon, Nov 28, 2016 at 1:23 PM, Artemiy Volkov <artemiyv@acm.org> wrote:
> Hi all,
>
> I've stumbled upon an issue when linking a lot of C++ template-heavy
> code into a single library with gold. To ensure that there's only one
> copy of each text section corresponding to an instantiation of a
> template function, it uses the comdat section mechanism, which is
> handled just fine for regular linking in relocate_section().
>
> However, for relocatable linking it uses scan_relocatable_relocs() +
> relocate_relocs(). AFAICT, scan_relocatable_relocs() is simply setting
> relocation strategy to RELOC_DISCARD for every relocation that refers
> to a section that's being discarded, and that's a problem for every
> comdat section except those whose contents end up being included in
> the output file. This way lots of relocations in the debug sections
> are discarded instead of adjusted and the debug information becomes
> unreliable.
>
> Is this a known problem? Or might I be doing something wrong?
Ping? Can anyone shed some light on this?
Thanks,
Artemiy