Bug 25031 - nm reports wrong address on 32bit
Summary: nm reports wrong address on 32bit
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: 2.34
: P2 normal
Target Milestone: 2.33
Assignee: Alan Modra
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-24 11:10 UTC by Gianfranco
Modified: 2019-09-26 21:16 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed: 2019-09-24 00:00:00


Attachments
example (1.32 KB, application/x-archive)
2019-09-24 11:10 UTC, Gianfranco
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gianfranco 2019-09-24 11:10:32 UTC
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
Comment 1 Gianfranco 2019-09-24 11:12:39 UTC
Please see this Debian discussion for more information
https://salsa.debian.org/reproducible-builds/diffoscope/issues/69
Comment 2 Sourceware Commits 2019-09-24 13:27:31 UTC
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.
Comment 3 Sourceware Commits 2019-09-25 02:19:19 UTC
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)
Comment 4 Alan Modra 2019-09-25 02:29:59 UTC
Fixed.
Comment 5 Gianfranco 2019-09-25 07:15:06 UTC
thanks a ton for the quick fixes!
Comment 6 Marc 2019-09-26 21:16:39 UTC
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.