Some Solaris versions contain ELFs (binaries, libraries) which have multiple .rodata sections: $ elfdump -c vgpreload_core-amd64-solaris.so Section Header[11]: sh_name: .rodata sh_addr: 0xf20 sh_flags: [ SHF_ALLOC ] sh_size: 0x41 sh_type: [ SHT_PROGBITS ] sh_offset: 0xf20 sh_entsize: 0 sh_link: 0 sh_info: 0 sh_addralign: 0x20 Section Header[12]: sh_name: .rodata sh_addr: 0xf61 sh_flags: [ SHF_ALLOC SHF_MERGE SHF_STRINGS ] sh_size: 0x3c sh_type: [ SHT_PROGBITS ] sh_offset: 0xf61 sh_entsize: 0x1 (60 entries) sh_link: 0 sh_info: 0 sh_addralign: 0x1 Section Header[13]: sh_name: .rodata sh_addr: 0xfa0 sh_flags: [ SHF_ALLOC SHF_MERGE SHF_STRINGS ] sh_size: 0x32 sh_type: [ SHT_PROGBITS ] sh_offset: 0xfa0 sh_entsize: 0x1 (50 entries) sh_link: 0 sh_info: 0 sh_addralign: 0x8 However Valgrind ELF debug info reader is confused about multiple .rodata sections and spits the following warning: --14073-- WARNING: Serious error when reading debug info --14073-- When reading debug info from vgpreload_core-amd64-solaris.so: --14073-- Can't make sense of .rodata section mapping It can be seen that these 3 .rodata sections have the same section name but they differ with flags and addralign. After some research it is evident that sections with SHF_STRINGS flag cannot contain any debug info - they just contain NULL-terminated strings. So these can be safely skipped.
Created attachment 94954 [details] proposed patch for all platforms
The algorithm which the ELF debug info reader utilizes is flawed. It iterates over well-known sections and remembers them for later use; for symbol lookup and DWARF expression evaluation, for example. However the correct approach would be to follow shndx of the symbol to the corresponding section. However this would bring unforeseen complications in terms of complex code and memory demand. So the proposed patch just skips .rodata sections which contain strings only; as they cannot contain any debug info there. This way the debug info reader "sees" only one .rodata section and everything works marvelously. I regression tested the patch on Solaris (x86+amd64) and Linux/Ubuntu (x86+amd64) platforms. In all cases, everything looks good.
re Comment 2 above: "the proposed patch just skips .rodata sections which contain strings only" should say instead "... skips .rodata which is marked by SHF_STRINGS, under the assumption that it contains no debug info." This is an *assumption* unless you can cite the guarantees. That property is not required nor enforced by DWARF. Also, please be specific about the fears "follow shndx of the symbol ... would bring unforeseen complications in terms of complex code and memory demand." It seems to me that a byte array whose length is the number of sections would be enough storage to accumulate the necessary information from a pre-pass which scans everything before starting the "real" processing. Or, such an array could accumulate enough state during a single pass to determine "online" whether a second pass is necessary, and how much it would be worth. Why is that so expensive?
Right, saying that ".rodata section with flag SHF_STRINGS contains just strings only" is an assumption which does not have any support. Let me rework the patch so that the debug info reader first determines the correct .rodata section which object symbols point to via shndx.
Also, it would be good if you could include, in comments, a reference to this bug. eg "(see https://bugs.kde.org/show_bug.cgi?id=353802)"
Created attachment 95081 [details] proposed patch #2 Reworked patch. On Solaris, there is a quick pre-scan of section headers for .rodata sections. If there are multiple .rodata sections present then symbols from .symtab are scanned which section they point to. The "true" .rodata section is thus determined.
Patch#2 looks good to me.
Fixed in SVN r15719.
Reverted by bug #360749.
This problem has re-appeared using GCC 8.x on Solaris 11.3 under valgrind git tip: commit dcb83cf846b529104cd528cd749b61f35deda476 Author: Rhys Kidd <rhyskidd@gmail.com> Date: Sun Feb 11 17:16:38 2018 -0500 The re-appearance was reported by Paul Floyd in [Valgrind-users] two days ago on 2018-02-11 with Subject: "rodata warning". The presenting symptom is: --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 will be attached. The Status of this bug 353802 should be re-opened (not Resolved Fixed). I will try, but might not have enough privilege to do so.
Created attachment 110638 [details] proposed workaround patch: read_elf_debug_info accepts contiguous .rodata* This patch compiles but is UNTESTED.
The re-appearance has been entered as separate bug report https://bugs.kde.org/show_bug.cgi?id=390871 at the request of Ivo Raisr.