[Bug binutils/24326] New: `nm` outputs symbol values of 0 for ft LTO object files
https://sourceware.org/bugzilla/show_bug.cgi?id=24326 Bug ID: 24326 Summary: `nm` outputs symbol values of 0 for ft LTO object files Product: binutils Version: 2.28 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: brandon.m.simmons at gmail dot com Target Milestone: --- If I compile a file `tmp.c`, that looks like: char constantFOO[0x12]; char constantBAR[0x34]; with `gcc -c tmp.c -o tmp.o && nm tmp.o`, nm outputs: 0034 C constantBAR 0012 C constantFOO But adding `-flto -ffat-lto-objects` to gcc flags, `nm` outputs: C constantBAR C constantFOO It was suggested this was a bug, here: https://stackoverflow.com/a/55127171/176841 -- 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
[Bug binutils/24326] `nm` outputs symbol values of 0 for ft LTO object files
https://sourceware.org/bugzilla/show_bug.cgi?id=24326 --- Comment #3 from Brandon Simmons --- Created attachment 11668 --> https://sourceware.org/bugzilla/attachment.cgi?id=11668&action=edit fat LTO object -- 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
[Bug binutils/24326] `nm` outputs symbol values of 0 for ft LTO object files
https://sourceware.org/bugzilla/show_bug.cgi?id=24326 --- Comment #2 from Brandon Simmons --- Sorry I meant to post gcc version. I'm on debian stretch and these are the versions available there $ nm --version GNU nm (GNU Binutils for Debian) 2.28 $ gcc --version gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 I also just noticed I get the same results (both files have roughly same size and contents, at a glance, and nm works the same) on both fat/not-fat: $ gcc -flto -ffat-lto-objects -c mytemp.c -o mytemp.o.ltofat $ gcc -flto -fno-fat-lto-objects -c mytemp.c -o mytemp.o.lto_nonfat I'm attaching both. Glad to know this might be a thing that's fixed in newer versions. Thanks! -- 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
[Bug binutils/24326] `nm` outputs symbol values of 0 for ft LTO object files
https://sourceware.org/bugzilla/show_bug.cgi?id=24326 --- Comment #4 from Brandon Simmons --- Created attachment 11669 --> https://sourceware.org/bugzilla/attachment.cgi?id=11669&action=edit no-fat-lto-object -- 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
[Bug binutils/24326] `nm` outputs symbol values of 0 for ft LTO object files
https://sourceware.org/bugzilla/show_bug.cgi?id=24326 --- Comment #6 from Brandon Simmons --- Ah, okay now we're getting somewhere. So it seems that the issue is related to the liblto plugin (which AIUI is enabled either by using gcc-nm, or by putting the plugin in the right place). So I think we may be observing the same behavior: My `nm` is not `gcc-nm`: jberryman /tmp » file $(which nm) 130 ↵ /usr/bin/nm: symbolic link to x86_64-linux-gnu-nm jberryman /tmp » file $(which x86_64-linux-gnu-nm) /usr/bin/x86_64-linux-gnu-nm: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=92954b72bc19e08b152f66b7a1ce5fb10d01f33c, stripped jberryman /tmp » file $(which gcc-nm) /usr/bin/gcc-nm: symbolic link to gcc-nm-6 jberryman /tmp » file $(which gcc-nm-6) /usr/bin/gcc-nm-6: symbolic link to x86_64-linux-gnu-gcc-nm-6 jberryman /tmp » file $(which x86_64-linux-gnu-gcc-nm-6) /usr/bin/x86_64-linux-gnu-gcc-nm-6: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=c042db1fc5f0c6375e2af5c34f1103d5f02233af, stripped ...but I DO have the plugin symlinked. So if I do: $ rm /usr/lib/bfd-plugins/liblto_plugin.so I find `nm` gives me same output as you see: jberryman /tmp » nm mytemp.o.ltofat 0034 C constantBAR 0012 C constantFOO 0001 C __gnu_lto_v1 Likewise same as you for non-fat lto object. And to be clear I'm not sure this is a bug (I'm pretty out of my depth), but it's behavior that caused an error in a big complicated OSS compiler project that I'm just starting to try to contribute to. -- 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
