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. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils