[Bug binutils/24326] `nm` outputs symbol values of 0 for ft LTO object files

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24326

--- Comment #5 from Nick Clifton <nickc at redhat dot com> ---
Hi Brandon,

  Interesting.  If I run nm on those two files I see:

  % nm mytemp.o.lto_nonfat mytemp.o.ltofat 

mytemp.o.lto_nonfat:
nm: mytemp.o.lto_nonfat: plugin needed to handle lto object
0000000000000001 C __gnu_lto_slim
0000000000000001 C __gnu_lto_v1

mytemp.o.ltofat:
0000000000000034 C constantBAR
0000000000000012 C constantFOO
0000000000000001 C __gnu_lto_v1

  But, if I run gcc-nm on them I see:

  % gcc-nm mytemp.o.lto_nonfat mytemp.o.ltofat 

mytemp.o.lto_nonfat:
00000000 C constantBAR
00000000 C constantFOO

mytemp.o.ltofat:
00000000 C constantBAR
00000000 C constantFOO

  So my guess is that you have nm aliased to gcc-nm.
  Now gcc-nm is effectively just a wrapper than runs nm with the plugin
  added, and this is confirmed by running the command directly:

  % nm mytemp.o.lto_nonfat mytemp.o.ltofat --plugin
/usr/libexec/gcc/x86_64-redhat-linux/8/liblto_plugin.so.0.0.0 

mytemp.o.lto_nonfat:
00000000 C constantBAR
00000000 C constantFOO

mytemp.o.ltofat:
00000000 C constantBAR
00000000 C constantFOO

  So at least you have a workaround for fatlto objects - use nm directly
  rather than via gcc-nm.

  I think that otherwise you might be stuck.  You see lto object files
  have not really been compiled yet.  They are in a kind of half way state
  been source and compilation, waiting for the full link-time-optimization
  compilation step to take place.  So there are no fully resolved symbols
  of the kind that you expect nm to report.  The names are there, but they
  have not been fully compiled just yet.  Does this make sense ?

Cheers
  Nick

-- 
You are receiving this mail because:
You are on the CC list for the bug.