binutils nm wrong output format breaks i386 nm work

Created attachment 12001
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

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 <email address hidden>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=352f6bc3e5b23e76d8e6f56fb7db4e57d8f5d5bd

commit 352f6bc3e5b23e76d8e6f56fb7db4e57d8f5d5bd
Author: Alan Modra <email address hidden>
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.

> on amd64 it works correctly:
>
> nm elfmix1.not_a
> return42_or_3_long_name.o:
> 0000000000000000 T return42_or_3
> return42_or_3_long_name.obj:
> 0000000000000000 T return42_or_3

No, on amd64 the bug is the same as on i386. The correct output on both i386 and amd64 must be:

return42_or_3_long_name.o:
0000000000000000 T return42_or_3
return42_or_3_long_name.obj:
00000000 T return42_or_3

The binutils-2_33-branch branch has been updated by Alan Modra <email address hidden>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=895b6d98785ba89819820aa5f4abed17fbb28c37

commit 895b6d98785ba89819820aa5f4abed17fbb28c37
Author: Alan Modra <email address hidden>
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.