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 binut...@sourceware.org.
Kind regards,
Nicolas
--
You are receiving this mail because:
You are on the CC list for the bug.
