On binutils configured with --enable-targets=x86_64-linux-gnu (target i486-linux-gnu) (or running on x86_64-linux-gnu with target i486-linuxaout (I suppose any target could show the bug as long as the utils run on x86_64)), nm and objdump, when run on a.out object files or executables (at least QMAGIC and OMAGIC flavours) show addresses on 64bits, which confuses old programmes which assume a 32 bit space addressing (namely dlltools). When the same utils are run on elf32 object files or executables the adresses are shown on 32bits. However if the host and targets are 32bits only the problem does not show. I suspect some kind of leak of the internal representation of addresses for these programmes.
It works for me. Please provide a QMAGIC file which shows the problem.
Created attachment 1656 [details] QMAGIC sample This sample was created with as and ld configured with host=x86_64-linux and target=i486-linuxaout. % file /opt/binutils-2.17-aout/i386-linuxaout/bin/nm /opt/binutils-2.17-aout/i386-linuxaout/bin/nm: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), for GNU/Linux 2.6.0, stripped % /opt/binutils-2.17-aout/i386-linuxaout/bin/nm affiche 0000000000001020 t affiche.o 0000000000002010 A __bss_start 0000000000002010 D _edata 0000000000002010 D __edata 0000000000002010 A _end 0000000000002010 A __end 0000000000001058 T _etext 0000000000001058 T __etext 000000000000102a t .L0 0000000000001037 t .L1 0000000000002000 d output 0000000000001020 T _start
That is normal since bfd_vma is 64bit on 64bit host. The same applies to any 32bit targets, including ELF/i386.
Created attachment 1657 [details] Make nm print addresses of symbols as 32-bit or 64-bit values, depending upon the size of the target
It is not just nm. Almost all programs in binutils behave the same when displaying address, either for output or error message. We should be very careful, not to hide problems. For example, when nm shows ffff0000 ... for 32bit file on 64bit host. We'd like to know the high 32bits since they may indicate problems in binutils itself.
Created attachment 1658 [details] Improved version of previous patch with better heuristics for guessing target address size
Subject: Re: nm and objdump show addresses on 64 bits for 32bit a.out files Hi Quentin, > target=i486-linuxaout. The problem here is that the aout file format does not specify the address size of the objects it contains, so the BFD library does not know whether the objects are 32-bit or 64-bit. Instead nm defaults to using the bitsize of the host. I have uploaded a patch which improves nm's heuristic. Now if the BFD library cannot tell it the bitsize of the target it will look at the target format's name. If the string "64" occurs anywhere in the name then it will assume a 64-bit bitsize, otherwise it will assume a 32-bit bitsize. Not perfect but I think that it should work most of the time. Please try out the patch and let me know what you think. Cheers Nick
(In reply to comment #7) > Subject: Re: nm and objdump show addresses on 64 bits > for 32bit a.out files > > > target=i486-linuxaout. > > The problem here is that the aout file format does not specify the > address size of the objects it contains, so the BFD library does not > know whether the objects are 32-bit or 64-bit. Instead nm defaults to > using the bitsize of the host. Or the maximum bitsize of its targets, as the problem also shows for 32bit tools but who can handle 64bit objects. > Please try out the patch and let me know what you think. It works, thanks (I suppose the work could also be done on objdump, to have a coherent behaviour), but it breaks the purpouse H.J. Lu mentioned. It's indeed not clear about what should be done, for multi-arch utils. Maybe a switch ? (but it would become much more than a small patch, and I don't want to have an argument with developpers)
Created attachment 1660 [details] Extend patch to affect objdump's output as well.
Subject: Re: nm and objdump show addresses on 64 bits for 32bit a.out files Hi Quentin, > It works, thanks (I suppose the work could also be done on objdump, to have a > coherent behaviour), but it breaks the purpouse H.J. Lu mentioned. Well I am not so sure about H.J.'s point. If I understand it correctly he wants addresses displayed as 64-bit values when running the tools on 64-bit hosts, even when the target file uses a 32-bit address space, in order to be able to check for internal bugs. To me it seems wrong to display a 32-bit address as a 64-bit value, since it implies that the address (and the space it is in) is in a 64-bit domain. I think that it would be better not to confuse the users of the tools, even if this makes it harder to track down internal bugs. (After all if we do suspect an internal bug we can always add printfs of our own to help track it down). Objdump already does the correct thing when displaying symbols from ELF files, so it only has problems with other file formats. I have created a revised patch which takes care of the other cases. Please give it a try. > It's indeed not clear about what should be done, for multi-arch utils. Maybe a > switch ? (but it would become much more than a small patch, and I don't want to > have an argument with developpers) No this should not be necessary. In my opinion addresses should always be displayed as values of the size if the target's address space. Cheers Nick
(In reply to comment #10) > Subject: Re: nm and objdump show addresses on 64 bits > for 32bit a.out files > > Objdump already does the correct thing when displaying symbols from ELF > files, so it only has problems with other file formats. I have created > a revised patch which takes care of the other cases. Please give it a try. As long as I can tell it works, for nm as well as objdump, for elf32 and a.out. Thanks.