Bug 390871 - ELF debug info reader confused with multiple .rodata* sections
Summary: ELF debug info reader confused with multiple .rodata* sections
Status: RESOLVED FIXED
Alias: None
Product: valgrind
Classification: Developer tools
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Paul Floyd
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-21 21:53 UTC by John Reiser
Modified: 2023-10-08 19:58 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
.rodata*: aggregate multiple adjacent sections after alignment (3.06 KB, patch)
2018-07-17 01:45 UTC, John Reiser
Details

Note You need to log in before you can comment on or make changes to this bug.
Description John Reiser 2018-02-21 21:53:04 UTC
Slightly edited from https://bugs.kde.org/show_bug.cgi?id=353802#c10 :

--18142-- WARNING: Serious error when reading debug info
--18142-- When reading debug info from /export/home/paulf/tools/gcc/lib/libstdc++.so.6.0.25:
--18142-- Can't make sense of .rodata section mapping

(GCC SVN head, Solaris 11.3, Valgrind git head).

This problem has appeared under valgrind git tip:
   commit dcb83cf846b529104cd528cd749b61f35deda476
   Author: Rhys Kidd <rhyskidd@gmail.com>
   Date:   Sun Feb 11 17:16:38 2018 -0500
The problem was reported by Paul Floyd in [Valgrind-users] ten days ago on 2018-02-11 with Subject: "rodata warning".

The cause appears to be hundreds of Elf32_Shdr (also Elf64_Shdr) with names .rodata and/or .rodata.<subr_name>.  Sample:
 Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [15] .rodata._ZNKSt10l PROGBITS        00093a88 093a88 000010 01 AMS  0   0  1
  [16] .rodata._ZNKSt12_ PROGBITS        00093a98 093a98 000008 01 AMS  0   0  1
  [17] .rodata._ZNKSt12_ PROGBITS        00093aa0 093aa0 000007 01 AMS  0   0  1
  [18] .rodata           PROGBITS        00093ac0 093ac0 003504 00   A  0   0 32
  [19] .rodata._ZTSNSt12 PROGBITS        00096fe0 096fe0 00002c 00   A  0   0 32
  [20] .rodata._ZTSNSt12 PROGBITS        00097020 097020 00002b 00   A  0   0 32
  [21] .rodata._ZNSt6chr PROGBITS        0009704b 09704b 000001 00   A  0   0  1
  [22] .rodata._ZNSt6chr PROGBITS        0009704c 09704c 000001 00   A  0   0  1
  [23] .rodata._ZNKSt9ba PROGBITS        0009704d 09704d 00000f 01 AMS  0   0  1
  [24] .rodata._ZNKSt16b PROGBITS        0009705c 09705c 000016 01 AMS  0   0  1
  [25] .rodata._ZNKSt20b PROGBITS        00097072 097072 00001a 01 AMS  0   0  1
  [26] .rodata._ZNKSt8ba PROGBITS        0009708c 09708c 00000e 01 AMS  0   0  1
  [27] .rodata._ZNKSt10b PROGBITS        0009709a 09709a 000010 01 AMS  0   0  1
  [28] .rodata           PROGBITS        000970ac 0970ac 0002b4 01 AMS  0   0  4
  [29] .rodata._ZNKSt9ex PROGBITS        00097360 097360 00000f 01 AMS  0   0  1
and there are 639 more .rodata* Sections in that one file.

Inspection shows that the .rodata* are adjacent after considering alignment.  Therefore a workaround might be for the debuginfo reader to aggregate them all into a single internal .rodata section.  A simple proposed patch is:
https://bugsfiles.kde.org/attachment.cgi?id=110638

[This is a different cause than the related https://bugs.kde.org/show_bug.cgi?id=353802 , and therefore Ivo Raisr requested a new bug report.]
Comment 1 Paul Floyd 2018-06-02 10:30:33 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.
Comment 2 Paul Floyd 2018-06-05 20:00:59 UTC
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
Comment 3 Mark Wielaard 2018-07-16 11:08:15 UTC
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?
Comment 4 John Reiser 2018-07-17 01:45:32 UTC
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.
Comment 5 Julian Seward 2018-08-06 08:53:06 UTC
Is this still valid, considering there's been at least one related
fix to the debuginfo reader recently?
Comment 6 John Reiser 2018-08-06 13:46:24 UTC
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.
Comment 7 Tyson Nottingham 2023-10-06 23:27:27 UTC
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.
Comment 8 Paul Floyd 2023-10-07 05:14:18 UTC
(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).
Comment 9 Paul Floyd 2023-10-07 14:06:44 UTC
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.
Comment 10 Tyson Nottingham 2023-10-07 19:02:22 UTC
(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
Comment 11 Paul Floyd 2023-10-07 19:40:03 UTC
(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.
Comment 12 Paul Floyd 2023-10-08 10:26:51 UTC
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?
Comment 13 Paul Floyd 2023-10-08 10:27:54 UTC
(and for John, sorry I mistyped your name in git commit --author)
Comment 14 Tyson Nottingham 2023-10-08 19:04:14 UTC
(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.
Comment 15 Paul Floyd 2023-10-08 19:58:42 UTC
OK, closing as fixed.