[PATCH] Use GCC LTO wrapper to get real symbols from LTO IR objects

[Richard Biener]

On Mon, 10 Feb 2020, H dot J dot  Lu wrote:

> On Mon, Feb 10, 2020 at 3:02 PM Alan Modra <amodra@gmail.com> wrote:
> >
> > Wow, that's a lot of work to get proper symbol type.  What happens if
> 
> Very true.  I couldn't come up with a better solution without changing plugin
> API.
> 
> > you run nm on a system where gcc isn't installed?  Or where the lto
> > version doesn't match?
> 
> I assume standard GCC installation directory layout like
> 
> PREFIX/libexec/gcc/TARGET/VERSION/liblto_plugin.so
> PREFIX/libexec/gcc/TARGET/VERSION/lto-wrapper
> 
> and
> 
> PREFIX/bin/TARGET-gcc
> 
> or
> 
> PREFIX/bin/gcc
> 
> If there is no gcc nor lto-wrapper at expected location, no real
> symbols will be used.  If LTO version doesn't match, it is a
> GCC installation problem.

GCC installation problem?  Uh.

The attempt to find the approprate GCC driver to do code generation
is bound to fail in interesting ways.  Not sure if the cases that
are fixed with this approach are better than the know shortcomings
of the symbol table part of the plugin API and the resulting
impreciseness of nm output.

For better heuristics you should probably parse the .comment section
of the object file which contains GCC version information:

> readelf -x 13 x.o 

Hex dump of section '.comment':
  0x00000000 00474343 3a202847 4e552920 31302e30 .GCC: (GNU) 10.0
  0x00000010 2e312032 30323030 33303520 28657870 .1 20200305 (exp
  0x00000020 6572696d 656e7461 6c2900            erimental).

which might help to disambiguate the choice between multiple
installed compiler candidates.

For SUSE installed systems it's common to have an "old"
lto-plugin but also newer compilers installed so using solely the
lto-plugin location is misleading.

As said, there's technically no way to get at the correct
lto-wrapper or compiler driver (for COLLECT_GCC) for an LTO
object.  The only solution is to extend the plugin API
(and the LTO bytecode symbol table).

Richard.