Summary: | nm reports wrong address on 32bit | ||
---|---|---|---|
Product: | binutils | Reporter: | Gianfranco <costamagnagianfranco> |
Component: | binutils | Assignee: | Alan Modra <amodra> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | marc.herbert+sourceware |
Priority: | P2 | ||
Version: | 2.34 | ||
Target Milestone: | 2.33 | ||
Host: | Target: | ||
Build: | Last reconfirmed: | 2019-09-24 00:00:00 | |
Attachments: | example |
Please see this Debian discussion for more information https://salsa.debian.org/reproducible-builds/diffoscope/issues/69 The master branch has been updated by Alan Modra <amodra@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=352f6bc3e5b23e76d8e6f56fb7db4e57d8f5d5bd commit 352f6bc3e5b23e76d8e6f56fb7db4e57d8f5d5bd Author: Alan Modra <amodra@gmail.com> Date: Tue Sep 24 22:47:13 2019 +0930 PR25031, nm reports wrong address on 32bit Using saved_format breaks when nm is presented with multiple object files, some 32-bit and some 64-bit. PR 25031 * nm.c (print_format_string): New. (get_print_format): Delete saved_format. Move earlier. (set_print_width): Call get_print_format. (print_value): Use print_format_string. The binutils-2_33-branch branch has been updated by Alan Modra <amodra@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=895b6d98785ba89819820aa5f4abed17fbb28c37 commit 895b6d98785ba89819820aa5f4abed17fbb28c37 Author: Alan Modra <amodra@gmail.com> Date: Tue Sep 24 22:47:13 2019 +0930 PR25031, nm reports wrong address on 32bit Using saved_format breaks when nm is presented with multiple object files, some 32-bit and some 64-bit. PR 25031 * nm.c (print_format_string): New. (get_print_format): Delete saved_format. Move earlier. (set_print_width): Call get_print_format. (print_value): Use print_format_string. (cherry picked from commit 352f6bc3e5b23e76d8e6f56fb7db4e57d8f5d5bd) Fixed. thanks a ton for the quick fixes! Impressively quick fix indeed, thanks! I haven't seen any test added though. While such ELF files shouldn't be common, it's a fairly basic feature and doesn't seem like requiring any complex test fixture, does it? Relying on diffoscope's test suite doesn't feel right. |
Created attachment 12001 [details] example This happens since binutils 2.32.51.20190611 (The Debian version mostly tracks svn) and it was working on 2.32-8 (updated to 20190424) to reproduce: nm elfmix1.not_a nm: 42-Mach-O.o: file format not recognized nm: 43-Mach-O.o: file format not recognized nm: Mach-O.o: file format not recognized return42_or_3_long_name.o: 0000000000000000 T return42_or_3 nm: return42_or_3_long_name.c: file format not recognized nm: regen_elfmix.sh: file format not recognized return42_or_3_long_name.obj: ffa49ce800000000 T return42_or_3 before, with old binutils it was printed correctly nm elfmix1.not_a nm: 42-Mach-O.o: file format not recognized nm: 43-Mach-O.o: file format not recognized nm: Mach-O.o: file format not recognized return42_or_3_long_name.o: 0000000000000000 T return42_or_3 nm: return42_or_3_long_name.c: file format not recognized nm: regen_elfmix.sh: file format not recognized return42_or_3_long_name.obj: 00000000 T return42_or_3 Looks like the returned output is half full of uninitialized values on amd64 it works correctly nm elfmix1.not_a nm: 42-Mach-O.o: file format not recognized nm: 43-Mach-O.o: file format not recognized nm: Mach-O.o: file format not recognized return42_or_3_long_name.o: 0000000000000000 T return42_or_3 nm: return42_or_3_long_name.c: file format not recognized nm: regen_elfmix.sh: file format not recognized return42_or_3_long_name.obj: 0000000000000000 T return42_or_3