SUMMARY Trying to load the debug info for a rust program fails: --1647944-- WARNING: Serious error when reading debug info --1647944-- When reading debug info from /home/dennis/build/valgrind/test-rust: --1647944-- Can't make sense of .rodata section mapping Bisect output: 5472a7a54000692f9f58e9b551d36b8c68c44873 is the first bad commit commit 5472a7a54000692f9f58e9b551d36b8c68c44873 Author: Jogn Reiser <jreiser@bitwagon.com> Date: Sat Oct 7 16:02:24 2023 +0200 Bug 390871 - ELF debug info reader confused with multiple .rodata* sections NEWS | 1 + coregrind/m_debuginfo/readelf.c | 53 +++++++++++++++++++++++------------------ STEPS TO REPRODUCE 1. Create an empty rust project using `cargo new foo` 2. Build binary with `cargo build` 3. Execute valgrind using `valgrind target/debug/foo` OBSERVED RESULT ==1647944== Memcheck, a memory error detector ==1647944== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==1647944== Using Valgrind-3.22.0.GIT and LibVEX; rerun with -h for copyright info ==1647944== Command: ./test-rust ==1647944== --1647944-- WARNING: Serious error when reading debug info --1647944-- When reading debug info from /home/dennis/build/valgrind/test-rust: --1647944-- Can't make sense of .rodata section mapping Hello, world! ==1647944== ==1647944== HEAP SUMMARY: ==1647944== in use at exit: 0 bytes in 0 blocks ==1647944== total heap usage: 14 allocs, 14 frees, 3,273 bytes allocated ==1647944== ==1647944== All heap blocks were freed -- no leaks are possible ==1647944== ==1647944== For lists of detected and suppressed errors, rerun with: -s ==1647944== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) EXPECTED RESULT The debug symbols should be properly parsed SOFTWARE/OS VERSIONS Linux xarchie 6.6.3-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 29 Nov 2023 00:37:40 +0000 x86_64 GNU/Linux ADDITIONAL INFORMATION
Do you get the same problem with Valgrind built from git HEAD?
(In reply to Paul Floyd from comment #1) > Do you get the same problem with Valgrind built from git HEAD? Yes, exact same behavior
OK I'll try to reproduce it.
Works OK for me on Fedora 39 amd64 rustc --version rustc 1.74.1 (a28077b28 2023-12-04) (Fedora 1.74.1-1.fc39)
Created attachment 164366 [details] Example binary file containing a hello world program file foo foo: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 4.4.0, BuildID[sha1]=65c7742a98850b66723b0c088d9dc219bb0a6434, with debug_info, not stripped
I've tried it both on arch linux and nix os 23.11 with identical results. rustc 1.74.1 (a28077b28 2023-12-04) llvm 16.0.6 cargo 1.49.0 (d00d64df9 2020-12-05)
(In reply to Dennis Kobert from comment #6) > I've tried it both on arch linux and nix os 23.11 with identical results. > rustc 1.74.1 (a28077b28 2023-12-04) > llvm 16.0.6 > cargo 1.49.0 (d00d64df9 2020-12-05) Arch Linux Linux archlinux 6.6.6-arch1-1 #1 SMP PREEMPT_DYNAMIC Mon, 11 Dec 2023 11:48:23 +0000 x86_64 GNU/Linux rustc 1.74.1 (a28077b28 2023-12-04) (Arch Linux rust 1:1.74.1-1) LLD 16.0.6 (compatible with GNU linkers) cargo 1.74.1 Still no problem. readelf -t ./target/debug/foo shows just the one rodata section [16] .rodata PROGBITS 0000000000048000 0000000000048000 0 0000000000006920 0000000000000000 0 16 [0000000000000002]: ALLOC
Oh, I might be using mold as a linker, let me double check that. I'm also not sure why my cargo version is so outdated but that shouldn't make a difference as it works on the nix system
Yes, sorry, it only fails when using mold as a linker. I still had set `alias cargo=mold -run cargo` in my shell config sorry about that
OK. --14745-- WARNING: Serious error when reading debug info --14745-- When reading debug info from /home/paulf/foo/target/debug/foo: --14745-- Can't make sense of .rodata section mapping Hello, world! [15] .rodata PROGBITS 000000000000f7f0 000000000000f7f0 0 0000000000005800 0000000000000000 0 16 [0000000000000002]: ALLOC [16] .debug_gdb_scripts PROGBITS 0000000000014ff0 0000000000014ff0 0 0000000000000022 0000000000000001 0 1 [0000000000000032]: ALLOC, MERGE, STRINGS [17] .rodata.cst4 PROGBITS 0000000000015014 0000000000015014 0 000000000000004c 0000000000000004 0 4 [0000000000000012]: ALLOC, MERGE [18] .rodata.cst8 PROGBITS 0000000000015060 0000000000015060 0 0000000000000040 0000000000000008 0 8 [0000000000000012]: ALLOC, MERGE [19] .rodata.cst16 PROGBITS 00000000000150a0 00000000000150a0 0 0000000000000250 0000000000000010 0 16 [0000000000000012]: ALLOC, MERGE [20] .rodata.cst32 PROGBITS 00000000000152f0 00000000000152f0 0 0000000000000060 0000000000000020 0 8 [0000000000000012]: ALLOC, MERGE I think that in all the other cases that I've seen the .rodata.xxx have always been contiguous following .rodata. Here there is [16] .debug_gdb_scripts between .rodata and .rodata.xxx
Should be fixed with these two commits. Can you confirm? commit e5b7c187b72a55fdf329973f213688bf55e9607b (HEAD -> master, origin/master, origin/HEAD) Author: Paul Floyd <pjfloyd@wanadoo.fr> Date: Fri Dec 22 20:16:04 2023 +0100 Skip updating rodata avma and tracing when there are non-contiguous rodata sections. commit 171eaee3bd3f83d2d8de363711ffeb27a18ef940 Author: Paul Floyd <pjfloyd@wanadoo.fr> Date: Fri Dec 22 19:59:56 2023 +0100 Bug 478837 - valgrind fails to read debug info for rust binaries mold produces binaries with non-contiguous .rodata and .rodata.xxx sections. The code that merges their addresses can only handle 1 rodata which means only contiguous sections can be merged. Since this now seems to be a "normal" case I've changed the warning message to be a SYMTAB_TRACE message.
(In reply to Paul Floyd from comment #11) > Should be fixed with these two commits. Can you confirm? Yes, works! Thanks a lot!
*** Bug 486538 has been marked as a duplicate of this bug. ***