weird behavior of .rodata section

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?

Reproduce the behavior with the cargo new hello, cargo build, and objdump -d -j .rodata commands in the issue, then compare the Rust binary with the C example. Inspect the generated ELF section and the GNU objdump interpretation to determine whether the defect belongs to Rust or the external tool. Done means establishing ownership and documenting or testing a confirmed fix.