weird behavior of .rodata section

[sykacek]

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 | less

I 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| less

produces

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?

[asquared31415]

I believe this is a case of objdump using various heuristics to determine whether data is code or not when using the --disassemble flag. The existence of a symbol nearby (for panic messages) might also affect heuristics.

You likely want one of the other flags that just shows the data in the section rather than attempts to parse it as assembly code.

@rustbot label -C-bug -needs-triage +C-discussion