RFC: How should the LTO plugin handle object files containing both LTO and non-LTO data ?

[Nick Clifton]

Hi Guys,

  These days it is possible to have an object file that contains both
  LTO binary data and non-LTO binary data.  (See the attached file for
  an example).  Running tools like nm and readelf on such files will
  produce different results, depending upon which symbol tables are
  read.  Furthermore linking against such a file will have different
  results depending upon whether the lto plugin is used or not.

  So I am wondering how this scenario ought to be handled.  As a first
  step I think that readelf ought to be taught how to read and display
  lto symbol tables and symbol extension data.

  Next I think that the best solution would be if the lto plugin were to
  examine the .symtab section of any file it is processing, and if it
  contains extra symbols, then add these to the internal symbol table
  that it builds.  I think that this would solve the problem for nm, but
  maybe not ld.

  I am still investigating this issue, but I wanted to ask the community
  as a whole if there were any thoughts on the matter.

Cheers
  Nick

PS.  Here is the example file.  It contains both LTO compiled objects
  and hand-written assembler.  Running nm on it will normally not
  display the test_and_set_bit symbol, even though it is there, because
  it is not an LTO symbol.  Running readelf, or nm without the
  lto_plugin will show the symbol.  Similarly a link against an object
  file containing an undefined reference to test_and_set_bit will fail
  if the lto plugin is present, but succeed otherwise.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: jj.o.xz
Type: application/x-xz
Size: 39000 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20201013/9d20e32f/attachment-0001.xz>