Re: [PATCH] PR ld/17975: Useless FILE entry in symbol table for linker generated symbols

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Sun, Feb 15, 2015 at 5:47 PM, Alan Modra <amodra@gmail.com> wrote:
> 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.
>

I will buy a STT_FILE symbol for local symbols.  I don't see
how useful it is for forced local symbols.  It is one thing to
add one STT_FILE symbol for all forced local symbols.  It
is another add to one STT_FILE symbol for each input file
with forced local symbols.  Given that no one has complained
about the incorrect STT_FILE symbol for so far, I think we
should just keep one STT_FILE symbol for all forced local
symbols.

-- 
H.J.