This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] PR ld/17975: Useless FILE entry in symbol table for linker generated symbols
- From: Alan Modra <amodra at gmail dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Mon, 16 Feb 2015 12:17:44 +1030
- Subject: Re: [PATCH] PR ld/17975: Useless FILE entry in symbol table for linker generated symbols
- Authentication-results: sourceware.org; auth=none
- References: <20150215184602 dot GA25935 at gmail dot com> <20150216010455 dot GB4274 at bubble dot grove dot modra dot org> <CAMe9rOpZWO=VQFdaY1pDE5gnKk6ivAQ-OurH4DoOvPZnOVQ9Dw at mail dot gmail dot com>
On Sun, Feb 15, 2015 at 05:15:51PM -0800, H.J. Lu wrote:
> On Sun, Feb 15, 2015 at 5:04 PM, Alan Modra <amodra@gmail.com> wrote:
> > On Sun, Feb 15, 2015 at 10:46:02AM -0800, H.J. Lu wrote:
> >> We output a NULL STT_FILE symbol for forced local symbols so that they
> >> are not associated with the STT_FILE symbol for real local symbols. This
> >> patch makes sure that the NULL STT_FILE symbol is placed before forced
> >> local symbols. OK for trunk? I will update other expected outputs
> >> after this patch has been checked in.
> >
> > Huh, silly me for not noticing that forced local symbols can currently
> > be associated with the wrong file. Hmm, they do of course belong with
> > a particular file. So...
> >
> > We could keep the file association, and do away with the NULL STT_FILE
> > file symbol:
> > - In elf_link_input_bfd, replace all calls to elf_link_output_sym
> > with another function that buffers up local symbols to an array
> > attached to the input bfd (I think outsymbols should be free for
> > this use).
> > - In bfd_elf_final_link, output the first all-zero symbol and section
> > symbols, then follow that with a pass over globals emitting the
> > forced-local symbols not associated with an input file (ie. those we
> > currently output on the second pass), and buffering up other
> > forced-local symbols to their input bfd. Then loop over input bfds
> > emitting the buffered local symbols. An input bfd with locals but
> > no initial STT_FILE symbol needs one to be added. An input bfd with
> > more than one STT_FILE symbol (ie. specifying more than one source
> > file) needs to have another STT_FILE symbol added before the
> > forced-local globals.
> > - Finally, output global symbols.
> >
> > How does that sound? Let me know if you're interested in implementing
> > this. If not, I'll find time this week.
> >
>
> There are a couple issues:
>
> 1. If the forced local symbols aren't sorted by input file, we may
> generate many redundant STT_FILE symbols.
No, because the above scheme buffers forced-local symbols to the
input file that defines them.
> 2. When the forced local symbols are sorted by input file, we still
> generate one STT_FILE symbol per input file with forced local
> symbols. We may wind with many STT_FILE symbols. You can
> try it on glibc and libstdc++.
Yes, you will get an extra STT_FILE symbol for objects that have more
than one STT_FILE and forced-local globals.
> In any case, how useful are they? Are they really needed?
That's open to debate. :) If you have debug info, no.
> FWIW, gold doesn't generate any those STT_FILE symbols.
Yes, well, gold is lacking in many of the corner cases that bfd ld
supports.
--
Alan Modra
Australia Development Lab, IBM