Open
Description
When I try to disassembly rust generated ELF binaries, GNU Development Tools (objdump) do not disassemble .rodata section correctly, although hexeditor can see the bytes correctly.
Issue can be reproduced by basic hello world example:
cargo new hello
cd hello
cargo build
objdump -d -j .rodata target/debug/hello | lessI expected to see something similar to this:
exe: file format elf64-x86-64
Disassembly of section .rodata:
0000000000002000 <_IO_stdin_used>:
2000: 01 00 02 00 68 65 6c 6c 6f 20 77 6f 72 6c 64 00 ....hello world.
This is disassembly of basic C hello world program (
// compile with
// gcc -Wall -g main.c -o exe
#include <stdio.h>
#include <stdlib.h>
int main(void){
printf("hello world\n");
return 0;
})
Instead, .rodata section is interpreted as asm instructions, running
objdump -d -j .rodata target/debug/hello| lessproduces
target/debug/hello: file format elf64-x86-64
Disassembly of section .rodata:
00000000000087e0 <_ZN12panic_unwind3imp6CANARY17h6073a8883560d24bE-0x317c>:
87e0: 48 rex.W
87e1: 65 6c gs insb (%dx),%es:(%rdi)
87e3: 6c insb (%dx),%es:(%rdi)
87e4: 6f outsl %ds:(%rsi),(%dx)
87e5: 2c 20 sub $0x20,%al
87e7: 77 6f ja 8858 <GCC_except_table123+0x94>
87e9: 72 6c jb 8857 <GCC_except_table123+0x93>
87eb: 64 21 0a and %ecx,%fs:(%rdx)
87ee: 00 00 add %al,(%rax)
87f0: d8 86 01 00 51 87 fadds -0x78aeffff(%rsi)
87f6: 01 00 add %eax,(%rax)
87f8: d4 (bad)
87f9: 87 01 xchg %eax,(%rcx)
87fb: 00 fe add %bh,%dh
87fd: 87 01 xchg %eax,(%rcx)
87ff: 00 a3 87 01 00 08 add %ah,0x8000187(%rbx)
8805: 88 01 mov %al,(%rcx)
8807: 00 53 88 add %dl,-0x78(%rbx)
880a: 01 00 add %eax,(%rax)
880c: 1f (bad)
880d: 88 01 mov %al,(%rcx)
880f: 00 74 88 01 add %dh,0x1(%rax,%rcx,4)
8813: 00 6b 88 add %ch,-0x78(%rbx)
8816: 01 00 add %eax,(%rax)
8818: 74 88 je 87a2 <GCC_except_table75+0x22>
881a: 01 00 add %eax,(%rax)
881c: c6 87 01 00 1d 88 01 movb $0x1,-0x77e2ffff(%rdi)
8823: 00 fc add %bh,%ah
8825: 87 01 xchg %eax,(%rcx)
8827: 00 32 add %dh,(%rdx)
8829: 88 01 mov %al,(%rcx)
882b: 00 29 add %ch,(%rcx)
882d: 88 01 mov %al,(%rcx)
882f: 00 32 add %dh,(%rdx)
8831: 88 01 mov %al,(%rcx)
8833: 00 27 add %ah,(%rdi)
8835: 87 01 xchg %eax,(%rcx)
8837: 00 2f add %ch,(%rdi)
8839: 88 01 mov %al,(%rcx)
883b: 00 fa add %bh,%dl
883d: 87 01 xchg %eax,(%rcx)
883f: 00 56 88 add %dl,-0x78(%rsi)
8842: 01 00 add %eax,(%rax)
8844: 4d 88 01 rex.WRB mov %r8b,(%r9)
8847: 00 56 88 add %dl,-0x78(%rsi)
884a: 01 00 add %eax,(%rax)
884c: fc cld
884d: 8c 01 mov %es,(%rcx)
...
000000000000d54b <_ZN4core7unicode12unicode_data11white_space14WHITESPACE_MAP17h3ae1cbce69a0f25aE>:
d54b: 02 02 02 02 02 02 02 02 02 03 03 01 01 01 00 00 ................
...
d56b: 01 00 00 00 00 00 00 00 02 02 00 00 00 00 00 02 ................
...
d5a7: 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 ................
...
d5cf: 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
...
d5eb: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
...
d64b: 00 dd f0 ff ff df f0 ff ff e1 f0 ff ff 02 00 00 ................
d65b: 00 00 00 00 00 02 00 00 00 00 00 00 00 07 00 00 ................
d66b: 00 00 00 00 00
Hello world string is obviously present at 0x87e0, bytes seem to be correct, so why objdump produces those instructions?
Meta
rustc --version --verbose:
rustc 1.87.0-nightly (96cfc7558 2025-02-27)
binary: rustc
commit-hash: 96cfc75584359ae7ad11cc45968059f29e7b44b7
commit-date: 2025-02-27
host: x86_64-unknown-linux-gnu
release: 1.87.0-nightly
LLVM version: 20.1.0
Issue was also produced on this machine
rustc 1.87.0 (17067e9ac 2025-05-09)
binary: rustc
commit-hash: 17067e9ac6d7ecb70e50f92c1944e545188d2359
commit-date: 2025-05-09
host: x86_64-unknown-linux-gnu
release: 1.87.0
LLVM version: 20.1.1
Is this a problem with rust or just with GNU Development Tools?