Re: [PATCH] more adjustments to elf_find_function

["Jan Beulich" <JBeulich at novell dot com>]

>>> Alan Modra <amodra@bigpond.net.au> 30.11.04 23:42:37 >>>
>I think this patch is wrong.  If we are generating object files
>according to the ELF spec, then any file symbols will come first.

We had this discussion a couple of weeks back. I needed the changed behaviour just because of the way ld -r behaves currently (and I consider it correct).

>"STT_FILE
>    Conventionally, the symbol's name gives the name of the source file
>    associated with the object file. A file symbol has STB_LOCAL
>    binding, its section index is SHN_ABS, and it precedes the other
>    STB_LOCAL symbols for the file, if it is present."

The question is what 'source file' here stands for. If it is really what the words mean, then (for the case of multiple source files) I can only interpret the wording as implying that there (a) can be multiple file symbols and (b) each of them precedes all STB_LOCAL symbols resulting from the respective source file. The only questionable thing then would be sequences of STT_FILE symbols without intervening other symbols (which gas currently produces); I would even consider these matching the standard * the file symbol getting associated with the subsequent 'normal' ones wold be the last one from the sequence.

>ie. any state machine tracking whether symbols are seen before/after a
>file symbol is a waste of time.  If ld -r is not placing all file
>symbols at the start, then that's a bug.

You wrote, when we discussed this in October, a mail ' Why "ld -r" should not be used as a replacement for "ar" ', but only from the perspective of section treatment. Whatever you may desire to add to it symbol-wise, you should consider that ld -r is, as where I was running into problems in building the Linux kernel, being in wide-spread use regardless of whether that's what it's actually intended for. If you made it move all file symbols to the start of the symbol table, then you'd loose all association between local symbols and their original source files. If I wanted to disambiguate (say in a debugger) the symbol name by prefixing it with its source file name, that wouldn't work anymore.

Anyway, I'll wait with checking this in (regardless of Nick's approval) until we come to some sort of consensus here. I would think, however, that even if there really was a need to change the behavior of ld -r, the changes suggested here wouldn't hurt (as they don't hurt for compiler-generated or otherwise single-sourced object files), they would just introduce a little more overhead.

Jan