[valgrind] [Bug 390871] ELF debug info reader confused with multiple .rodata* sections
https://bugs.kde.org/show_bug.cgi?id=390871 Paul Floyd changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #15 from Paul Floyd --- OK, closing as fixed. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390871] ELF debug info reader confused with multiple .rodata* sections
https://bugs.kde.org/show_bug.cgi?id=390871 --- Comment #14 from Tyson Nottingham --- (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. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390871] ELF debug info reader confused with multiple .rodata* sections
https://bugs.kde.org/show_bug.cgi?id=390871 --- Comment #13 from Paul Floyd --- (and for John, sorry I mistyped your name in git commit --author) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390871] ELF debug info reader confused with multiple .rodata* sections
https://bugs.kde.org/show_bug.cgi?id=390871
--- Comment #12 from Paul Floyd ---
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?
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 390871] ELF debug info reader confused with multiple .rodata* sections
https://bugs.kde.org/show_bug.cgi?id=390871 Sam James changed: What|Removed |Added CC||s...@gentoo.org -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390871] ELF debug info reader confused with multiple .rodata* sections
https://bugs.kde.org/show_bug.cgi?id=390871 --- Comment #11 from Paul Floyd --- (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. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390871] ELF debug info reader confused with multiple .rodata* sections
https://bugs.kde.org/show_bug.cgi?id=390871 --- Comment #10 from Tyson Nottingham --- (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 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390871] ELF debug info reader confused with multiple .rodata* sections
https://bugs.kde.org/show_bug.cgi?id=390871 --- Comment #9 from Paul Floyd --- 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. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390871] ELF debug info reader confused with multiple .rodata* sections
https://bugs.kde.org/show_bug.cgi?id=390871 --- Comment #8 from Paul Floyd --- (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). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390871] ELF debug info reader confused with multiple .rodata* sections
https://bugs.kde.org/show_bug.cgi?id=390871 Paul Floyd changed: What|Removed |Added Assignee|jsew...@acm.org |pjfl...@wanadoo.fr -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390871] ELF debug info reader confused with multiple .rodata* sections
https://bugs.kde.org/show_bug.cgi?id=390871 tgnotting...@gmail.com changed: What|Removed |Added CC||tgnotting...@gmail.com --- Comment #7 from tgnotting...@gmail.com --- 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. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390871] ELF debug info reader confused with multiple .rodata* sections
https://bugs.kde.org/show_bug.cgi?id=390871 --- Comment #6 from John Reiser --- 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. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390871] ELF debug info reader confused with multiple .rodata* sections
https://bugs.kde.org/show_bug.cgi?id=390871 --- Comment #5 from Julian Seward --- Is this still valid, considering there's been at least one related fix to the debuginfo reader recently? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390871] ELF debug info reader confused with multiple .rodata* sections
https://bugs.kde.org/show_bug.cgi?id=390871 --- Comment #4 from John Reiser --- Created attachment 113979 --> https://bugs.kde.org/attachment.cgi?id=113979=edit .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. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390871] ELF debug info reader confused with multiple .rodata* sections
https://bugs.kde.org/show_bug.cgi?id=390871 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #3 from Mark Wielaard --- 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? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390871] ELF debug info reader confused with multiple .rodata* sections
https://bugs.kde.org/show_bug.cgi?id=390871 Florian Weimer changed: What|Removed |Added CC||fwei...@redhat.com -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390871] ELF debug info reader confused with multiple .rodata* sections
https://bugs.kde.org/show_bug.cgi?id=390871 --- Comment #2 from Paul Floyd --- 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 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390871] ELF debug info reader confused with multiple .rodata* sections
https://bugs.kde.org/show_bug.cgi?id=390871 Paul Floyd changed: What|Removed |Added CC||pa...@free.fr --- Comment #1 from Paul Floyd --- 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. -- You are receiving this mail because: You are watching all bug changes.
