[PATCH 1/3] Add native ELF and LTO support in collect2

[Dave Korn]

On 11/10/2010 16:54, Andi Kleen wrote:
>>   I'm not clear here: by "an ELF plugin", do you mean one that would return
>> the native ELF symbols rather than LTO ones?  Wouldn't need to be a new plugin
>> at all, that could easily be done by sending a plugin option to the existing one.
> 
> The existing plugin only does LTO, not native ELF.

  That didn't make anything clearer, I already understood that you were
talking about a plugin that "does" something with ELF, I was trying to get you
to tell me what that "something" was.  I'm going to assume the answer to my
first question was "yes", and your phrase "an ELF plugin" does indeed mean one
that would read the ELF native symbol table rather than the LTO symtab section.

>>> One thing I considered was calling nm with plugin or calling
>>> a new lto-nm I wrote, but just doing it directly was much nicer.
>>   Or, as you say, could use nm with the plugin.  I think reusing code is
>> "nicer" than copy-pasting it with minor variations into multiple locations.  I
>> think it would be really nice clean design if we had just one plugin, capable
>> of doing "whatever we want", and used it in as many locations as we can, using
>> a consistent plugin API.
> 
> I think you're missing the point. collect2 does far more than the linker plugin 
> does.
> 
> e.g. it scans for all kinds of different sections and does other special
> magic, which is not done by the LTO plugin which just looks through the 
> symbol table.

  But I think you're missing my point: collect2 "does" all those other things
*by means of* looking at the symbol table, doesn't it?  Which is what the
lto-plugin a) already does for LTO symbols and b) could trivially easily do
likewise for the native ELF symbols.  Unless I've overlooked something?

> The code to read the LTO symbol table is also quite small, about 40 lines
> or so. I don't think it makes sense to go through connotations just
> to share it.  The code to dynamically link the plugin would be also far
> from being system independent.

  Ah, that's actually a problem that would require libltdl, and even then
might not be possible on all host platforms.  Which is a shame, because I'd
really like it if we could control the proliferation of target object-format
dependent code and have it somehow centralized or abstracted, and the linker
plugin seemed like a good place to do so.  We could then have started getting
rid of the existing OBJECT_FORMAT_xxx code in collect2.  I have to admit
though that I don't know enough about the entire range of GCC targets to know
if this would be a sufficiently portable solution, but it ought to work for
ELF and COFF.

    cheers,
      DaveK