Summary: | ELF debug info reader confused with multiple .rodata* sections | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | John Reiser <jreiser> |
Component: | general | Assignee: | Paul Floyd <pjfloyd> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | fweimer, mark, pjfloyd, sam, tgnottingham |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | .rodata*: aggregate multiple adjacent sections after alignment |
Description
John Reiser
2018-02-21 21:53:04 UTC
I can confirm that the attached patch resolves the problem. I've just asked on the GCC mailing list if anyone knows why so many sections get generated. Mail from Rainer Orth on GCC mailing list those sections are in libstdc++.so. They can be found in the input objects used to created libstdc++.so on Linux and Solaris alike, due to the use of -fdata-sections (via SECTION_FLAGS) in libstdc++. However, on Linux gld is usually used, which is driven by linker maps that often coalesce sections based on section name patters. OTOH, Solaris ld (which I assume you used) usually doesn't care about section names, but does the bulk of its work based on section attributes alone. The ultimate result is the same (all .rodata* sections land in the read-only text segment at runtime), since sections don't matter to the kernel, only segments do. You can read about the gory details on how Solaris ld does that part of its work at https://docs.oracle.com/cd/E37838_01/html/E36783/gjqaz.html#scrolltoc (and doubtlessly somewhere on linker-aliens.org ;-) In Solaris 11.4, there were some changes here for better GNU (bug) compatibility, so there's only a single .rodata section here. However, there's nothing wrong with how Solaris ld behaved before: I'd claim this is a scalability bug in valgrind: ELF objects can have very large numbers of sections for all sorts of legitimate resons, so it needs to cope with them. Rainer https://bugs.kde.org/show_bug.cgi?id=395682#c9 touches the same area of code. Could you take a look how this proposed patch/bug interacts with that one? Created attachment 113979 [details] .rodata*: aggregate multiple adjacent sections after alignment Revise (and obsolete) the previous patch because of the intervening https://bugs.kde.org/show_bug.cgi?id=395682#c9 . This patch applies and compiles on top of 64aa729bfae71561505a40c12755bd6b55bb3061 dated Thu Jul 12 13:56:00 2018 +0200. Testing is needed; the complexity is growing. Is this still valid, considering there's been at least one related fix to the debuginfo reader recently? I believe that this bug and revised patch still are valid. The intervening https://bugs.kde.org/show_bug.cgi?id=395682#c9 is a distinct issue regarding .rodata for multiple segments. That bug does not address the handling of multiple adjacent (after alignment) .rodata* sections within the same segment. I ran into this issue when compiling a Rust program that uses eBPF with the mold linker. The use of eBPF causes there to be two identically named .rodata sections, and the version of mold that I'm using doesn't coalesce them. Valgrind emits the warning in the original post, and doesn't include a lot of symbol names in the files produced by Callgrind, etc., rendering them not-so-useful. The proposed patch doesn't apply cleanly anymore, but with some modifications, I found that it does seem to fix the problem. (In reply to Tyson Nottingham from comment #7) > I ran into this issue when compiling a Rust program that uses eBPF with the > mold linker. Can you provide an example? Since I originally reported this I can test of Solaris 11.3 (if I can get my own build of GCC to work). The problem seems to have gone away on Solaris. GCC has dropped Solaris 11.3, and the latest build I have is g++ (GCC) 12.0.1 20220425 (experimental) Syill, the patch looks good so I'll test it and push if it breaks nothing. (In reply to Paul Floyd from comment #8) > (In reply to Tyson Nottingham from comment #7) > > I ran into this issue when compiling a Rust program that uses eBPF with the > > mold linker. > > Can you provide an example? Sure, though I'm only able to give repro steps geared towards Ubuntu. https://github.com/tgnottingham/valgrind-ebpf-rodata-bug (In reply to Tyson Nottingham from comment #10) > Sure, though I'm only able to give repro steps geared towards Ubuntu. > > https://github.com/tgnottingham/valgrind-ebpf-rodata-bug OK thanks, I'll try to test it on Fedora tomorrow. Not sure what's missing. With Fedora 38 I get Compiling valgrind-ebpf-rodata-bug v0.1.0 (/home/paulf/valgrind-ebpf-rodata-bug) error: failed to run custom build command for `valgrind-ebpf-rodata-bug v0.1.0 (/home/paulf/valgrind-ebpf-rodata-bug)` Caused by: process didn't exit successfully: `/home/paulf/valgrind-ebpf-rodata-bug/target/release/build/valgrind-ebpf-rodata-bug-faba69e7e7dd97a3/build-script-build` (exit status: 101) --- stdout cargo:rerun-if-changed=src/bpf/tc.bpf.c --- stderr thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', build.rs:24:10 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace but I also hace mold 2.1.0 (compatible with GNU ld) I pushed a change, cold you confirm that it is ok? (and for John, sorry I mistyped your name in git commit --author) (In reply to Paul Floyd from comment #12) > I pushed a change, cold you confirm that it is ok? Yes, it appears to resolve the problem. OK, closing as fixed. |