| Summary: | valgrind fails to read debug info for rust binaries | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Dennis Kobert <dennis> |
| Component: | general | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | limuyang202011, pjfloyd |
| Priority: | NOR | ||
| Version First Reported In: | 3.22.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | Example binary file containing a hello world program | ||
|
Description
Dennis Kobert
2023-12-21 13:32:10 UTC
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. *** |