Hi Paul, > I was only talking about adding support to aligned new/delete on Valgrind > (here is the bugzilla entry I created if you are interested > https://bugs.kde.org/show_bug.cgi?id=388787 > <https://bugs.kde.org/show_bug.cgi?id=388787>) > > On Solaris (I’m using 11.3) Valgrind is having problems because of the > large number of .rodate sections. I haven’t seen this problem on Linux. > > Here again are the details: > > > Currently Valgrind can’t cope with the .rodata sections that get generated > (see bugzilla https://bugs.kde.org/show_bug.cgi?id=390871 > <https://bugs.kde.org/show_bug.cgi?id=390871><https://bugs.kde.org/show_bug.cgi?id=390871 > <https://bugs.kde.org/show_bug.cgi?id=390871>>) > > Here’s an extract from the report > > --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 > > 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 > <https://bugsfiles.kde.org/attachment.cgi?id=110638> > <https://bugsfiles.kde.org/attachment.cgi?id=110638 > <https://bugsfiles.kde.org/attachment.cgi?id=110638>> > The above patch does fix the problem. > Any idea why so many sections are getting generated? (The test case is > trivially small)
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 -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University
