[Bug binutils/31096] nm for mips32 (native or cross-compiled) shows 32bit addresses as sign-extended 64bit addresses

[n.schier at avm dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=31096

--- Comment #2 from Nicolas Schier <n.schier at avm dot de> ---
Hi Nick,

(In reply to Nick Clifton from comment #1)
> Hi Nicolas,
> 
>   This is actually expected behaviour.
> 
>   The MIPS architecture uses a signed address space, and tools configured to
> support the MIPS are aware of this.  Hence the mips-linux-gnu-nm tool
> displays a signed address.  Some tools however can be used on architectures
> for which they were not configured.  Nm is one of these tools.  So if you
> use x86_64-linux-gnu-nm on a MIPS binary, it will be able to display the
> symbols, but it will display their addresses as unsigned values, since that
> is how the x86_64 architecture treats its addresses.
> 
>   Basically if you want to discover information about MIPS binaries, use
> tools that are configured to support the MIPS architecture.

thanks for the insights and explanations, I am still a bit bewildered of 
"signed address space" and its implications.  The most irritating thing for me
is still that a mip32-native `nm` shows addresses of a mips32-native binary as
64-bit addresses, while mips32-native `objdump` shows 32-bit addresses:

    $ objdump -t ../my-mips32-binary 

    ../my-mips32-binary:     file format elf32-tradlittlemips

    SYMBOL TABLE:
    80000000 l    d  .note.gnu.build-id     00000000 .note.gnu.build-id
    80000030 l    d  .text  00000000 .text
    [...]
    00000000 l    df *ABS*  00000000 test.c
    80000030 g     F .text  00000024 test

    $ nm ../my-mips32-binary
    ffffffff80000030 T test

For my local work, a simple patch such as:

diff --git a/binutils/nm.c b/binutils/nm.c
index e4c8036df1b..7e42ce8f469 100644
--- a/binutils/nm.c
+++ b/binutils/nm.c
@@ -1821,6 +1821,9 @@ print_value (bfd *abfd ATTRIBUTE_UNUSED, bfd_vma val)
   switch (print_width)
     {
     case 32:
+      printf (print_format_string, 0xffffffff & (uint64_t) val);
+      break;
+
     case 64:
       printf (print_format_string, (uint64_t) val);
       break;

would be sufficient to get the output that I expect:

    $ binutils/nm-new ../mips32-test
    80000030 T test

here, `nm-new` is a mips32-native `nm`.  A native mips64el build of `nm`
shows this:

    $ binutils/nm-new /tmp/mips64el-test 
    0000000080000030 T test
    $ binutils/nm-new /tmp/mips32-test 
    80000030 T test

which is exactly what I had originally expected.

Am I still missing some point?  Is it really intended that `nm` shows 64-bit
addresses for mips32 targets?

If not, I plan to forward the patch to binutils@sourceware.org.

Kind regards,
Nicolas

-- 
You are receiving this mail because:
You are on the CC list for the bug.