|
From: Paul F. <pj...@wa...> - 2018-02-11 18:38:46
|
Hi I’m getting this warning: --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). Is it significant? Is there anything I can do about it? Regards Paul |
|
From: John R. <jr...@bi...> - 2018-02-11 20:36:11
|
> --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).
What does
readelf --headers .../libstdc++.so.6.0.25
say about the ElfXX_Shdrs and ElfXX_Phdrs,
and the mapping of the Shdrs into the Phdrs ?
|
|
From: Paul F. <pj...@wa...> - 2018-02-12 20:59:47
|
> On 11 Feb 2018, at 21:36, John Reiser <jr...@bi...> wrote: > >> --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). > > What does > readelf --headers .../libstdc++.so.6.0.25 > say about the ElfXX_Shdrs and ElfXX_Phdrs, > and the mapping of the Shdrs into the Phdrs ? > One more thing - I get the same with both 32bit and 64bit executables. A+ Paul |
|
From: Paul F. <pj...@wa...> - 2018-02-11 21:17:26
|
> On 11 Feb 2018, at 21:36, John Reiser <jr...@bi...> wrote: > >> --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). > > What does > readelf --headers .../libstdc++.so.6.0.25 > say about the ElfXX_Shdrs and ElfXX_Phdrs, > and the mapping of the Shdrs into the Phdrs ? > > BTW I’m not really expecting any issues with rodata. I don’t see any Elf hdrs as above in the output. A+ Paul |
|
From: Ivo R. <iv...@iv...> - 2018-02-12 12:53:14
|
2018-02-11 22:17 GMT+01:00 Paul Floyd <pj...@wa...>:
>
>
>> On 11 Feb 2018, at 21:36, John Reiser <jr...@bi...> wrote:
>>
>>> --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).
>>
>> What does
>> readelf --headers .../libstdc++.so.6.0.25
>> say about the ElfXX_Shdrs and ElfXX_Phdrs,
>> and the mapping of the Shdrs into the Phdrs?
I don't have libstdc++.so.6.0.25.
I have stock libstdc++.so.6.0.21 which is installed with Solaris 11.3
SRU 28 (currently the latest).
readelf --headers /usr/lib/64/libstdc++.so.6.0.21 returns:
ELF Header:
Magic: 7f 45 4c 46 02 01 01 06 01 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - Solaris
ABI Version: 1
Type: DYN (Shared object file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x0
Start of program headers: 64 (bytes into file)
Start of section headers: 11713976 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 5
Size of section headers: 64 (bytes)
Number of section headers: 2148
Section header string table index: 2146
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .dynamic DYNAMIC 0000000000000158 00000158
0000000000000370 0000000000000010 A 8 0 8
[ 2] .eh_frame_hdr X86_64_UNWIND 00000000000004c8 000004c8
0000000000007f44 0000000000000000 A 0 0 8
[ 3] .eh_frame X86_64_UNWIND 0000000000008410 00008410
0000000000023b5c 0000000000000000 A 0 0 8
[ 4] .SUNW_syminfo VERDEF 000000000002bf70 0002bf70
000000000000541c 0000000000000004 AI 7 1 8
[ 5] .hash HASH 0000000000031390 00031390
000000000000a838 0000000000000004 A 7 0 8
[ 6] .SUNW_ldynsym LOOS+ffffff3 000000000003bbc8 0003bbc8
0000000000005868 0000000000000018 A 8 943 8
[ 7] .dynsym DYNSYM 0000000000041430 00041430
000000000001f8a8 0000000000000018 A 8 2 8
[ 8] .dynstr STRTAB 0000000000060cd8 00060cd8
000000000004b69a 0000000000000000 AS 0 0 1
[ 9] .SUNW_version VERNEED 00000000000ac378 000ac378
0000000000000100 0000000000000001 A 8 4 8
[10] .SUNW_version VERDEF 00000000000ac478 000ac478
00000000000004c4 0000000000000001 A 8 35 8
[11] .SUNW_versym VERSYM 00000000000ac940 000ac940
0000000000002a0e 0000000000000002 A 7 0 8
[12] .SUNW_dynsymsort LOOS+ffffff1 00000000000af350 000af350
0000000000005ddc 0000000000000004 A 6 0 8
[13] .SUNW_dyntlssort LOOS+ffffff2 00000000000b5130 000b5130
0000000000000008 0000000000000004 A 6 0 8
[14] .SUNW_reloc RELA 00000000000b5138 000b5138
0000000000017160 0000000000000018 A 7 0 8
[15] .rela.plt RELA 00000000000cc298 000cc298
0000000000004c98 0000000000000018 AI 7 1916 8
[16] .gcc_except_table PROGBITS 00000000000d0f30 000d0f30
0000000000007232 0000000000000000 A 0 0 4
[17] .rodata.str1.1 PROGBITS 00000000000d8162 000d8162
0000000000000ce2 0000000000000001 AMS 0 0 1
[18] .rodata._ZTSSt10l PROGBITS 00000000000d8e48 000d8e48
000000000000000f 0000000000000000 A 0 0 8
[19] .rodata._ZTSSt14e PROGBITS 00000000000d8e60 000d8e60
0000000000000013 0000000000000000 A 0 0 16
[...and much more .rodata_* sections, up to...]
[2147] .SUNW_signature GNU_HASH 0000000000000000 00b2bc1e
0000000000000198 0000000000000000 E 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x00000000001a6f65 0x00000000001a6f65 R E 100000
LOAD 0x00000000001a7000 0x00000000002a7000 0x0000000000000000
0x000000000000bd78 0x000000000000f850 RW 100000
DYNAMIC 0x0000000000000158 0x0000000000000158 0x0000000000000000
0x0000000000000370 0x0000000000000000 RW 0
TLS 0x00000000001b2d78 0x00000000002b2d78 0x0000000000000000
0x0000000000000000 0x0000000000000020 RW 8
LOOS+464e550 0x00000000000004c8 0x00000000000004c8 0x0000000000000000
0x0000000000007c14 0x0000000000007c14 R 8
Section to Segment mapping:
Segment Sections...
00 .dynamic .eh_frame_hdr .eh_frame .SUNW_syminfo .hash
.SUNW_ldynsym .dynsym .dynstr .SUNW_version .SUNW_version .SUNW_versym
.SUNW_dynsymsort .SUNW_dyntlssort .SUNW_reloc .rela.plt
.gcc_except_table .rodata.str1.1 .rodata._ZTSSt10lock_error
.rodata._ZTSSt14error_category
.rodata._ZTSNSt12_GLOBAL__N_122generic_error_categoryE
.rodata._ZTSNSt12_GLOBAL__N_121system_error_categoryE
.rodata._ZNSt6chrono12system_clock12is_monotonicE
.rodata._ZTSNSt13__future_base11_State_baseE
.rodata._ZTSNSt13__future_base19_Async_state_commonE
.rodata._ZNSt6chrono12system_clock9is_steadyE
.rodata._ZTSN10__cxxabiv117__array_type_infoE ... [much more entries]
01 .got .fini_array .init_array .data .jcr .tm_clone_table
.data._ZL16__gthread_active
.data.rel.ro._ZTINSt12_GLOBAL__N_122generic_error_categoryE
.data.rel.ro._ZTINSt12_
GLOBAL__N_121system_error_categoryE
.data.rel.ro._ZTVNSt12_GLOBAL__N_122generic_error_categoryE
.data.rel.ro._ZTVNSt12_GLOBAL__N_121system_error_categoryE
.data._ZZL18__gthread_
active_pvE22__gthread_active_mutex
.data._ZZN12_GLOBAL__N_116get_atomic_mutexEvE12atomic_mutex
.data.rel._ZN10__cxxabiv119__terminate_handlerE
.data.rel._ZN10__cxxabiv120__unexp
ected_handlerE .data.rel.ro.local
.data.rel.ro._ZNSt6locale17_S_twinned_facetsE
.data.rel.ro._ZNSt6locale5_Impl19_S_facet_categoriesE
.data.rel.ro._ZNSt6locale5_Impl14_S_id_mess
agesE .data.rel.ro._ZNSt6locale5_Impl14_S_id_monetaryE
.data.rel.ro._ZNSt6locale5_Impl10_S_id_timeE
.data.rel.ro._ZNSt6locale5_Impl13_S_id_collateE
.data.rel.ro._ZNSt6locale5_Im
pl13_S_id_numericE .data.rel.ro._ZNSt6locale5_Impl11_S_id_ctypeE
.data.rel.local._ZNSt10__num_base12_S_atoms_outE
.data.rel.local._ZNSt10__num_base11_S_atoms_inE .data.rel.local
._ZNSt10money_base8_S_atomsE
.data.rel.local._ZNSt17__timepunct_cacheIwE12_S_timezonesE
.data.rel.local._ZNSt17__timepunct_cacheIcE12_S_timezonesE
.data.rel.ro.local._ZNSt6local
e13_S_categoriesE .data.rel.ro.local._ZN9__gnu_cxxL14category_namesE
.data.rel.ro.local._ZZNK11__gnu_debug16_Error_formatter10_Parameter14_M_print_fieldEPKS0_PKcE13__state_names
.data.rel.ro.local._ZZNK11__gnu_debug16_Error_formatter10_Parameter14_M_print_fieldEPKS0_PKcE17__constness_names
.data.rel.local._ZN11__gnu_debug17_S_debug_messagesE .data.rel.
local._ZZN12_GLOBAL__N_126__future_category_instanceEvE5__fec ....
[much more entries]
02
03 .tbss._ZZN12_GLOBAL__N_110get_globalEvE6global
.tbss._ZSt11__once_call .tbss._ZSt15__once_callable
04
Valgrind version valgrind-3.14.0.GIT-5a705cfa90-20180118 on Solaris
11.3 x86 has no problem reading debug info from this libstdc++.so.
There is also native Solaris utility called "elfdump".
You can invoke 'elfdump -p -c -s' on libstdc++.so.6.0.21 and
libstdc++.so.6.0.25 and compare for significant differences.
I.
|
|
From: John R. <jr...@bi...> - 2018-02-11 21:39:32
|
>>> --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).
>> What does
>> readelf --headers .../libstdc++.so.6.0.25
>> say about the ElfXX_Shdrs and ElfXX_Phdrs,
>> and the mapping of the Shdrs into the Phdrs ?
> I don’t see any Elf hdrs as above in the output.
Here is the output on Linux. Is there something equivalent on Solaris?
======
$ readelf --headers /lib64/libstdc++.so.6
ELF Header:
Magic: 7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - GNU
ABI Version: 0
Type: DYN (Shared object file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x8b880
Start of program headers: 64 (bytes into file)
Start of section headers: 1588608 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 8
Size of section headers: 64 (bytes)
Number of section headers: 33
Section header string table index: 32
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .note.gnu.build-i NOTE 0000000000000200 00000200
0000000000000024 0000000000000000 A 0 0 4
[ 2] .gnu.hash GNU_HASH 0000000000000228 00000228
0000000000008410 0000000000000000 A 3 0 8
[ 3] .dynsym DYNSYM 0000000000008638 00008638
00000000000205e0 0000000000000018 A 4 3 8
[ 4] .dynstr STRTAB 0000000000028c18 00028c18
0000000000040f7f 0000000000000000 A 0 0 1
[ 5] .gnu.version VERSYM 0000000000069b98 00069b98
0000000000002b28 0000000000000002 A 3 0 2
[ 6] .gnu.version_d VERDEF 000000000006c6c0 0006c6c0
000000000000050c 0000000000000000 A 4 37 8
[ 7] .gnu.version_r VERNEED 000000000006cbd0 0006cbd0
0000000000000100 0000000000000000 A 4 4 8
[ 8] .rela.dyn RELA 000000000006ccd0 0006ccd0
0000000000016aa0 0000000000000018 A 3 0 8
[ 9] .rela.plt RELA 0000000000083770 00083770
0000000000004ce0 0000000000000018 AI 3 27 8
[10] .init PROGBITS 0000000000088450 00088450
0000000000000017 0000000000000000 AX 0 0 4
[11] .plt PROGBITS 0000000000088470 00088470
0000000000003350 0000000000000010 AX 0 0 16
[12] .plt.got PROGBITS 000000000008b7c0 0008b7c0
00000000000000b8 0000000000000000 AX 0 0 8
[13] .text PROGBITS 000000000008b880 0008b880
00000000000af149 0000000000000000 AX 0 0 16
[14] .fini PROGBITS 000000000013a9cc 0013a9cc
0000000000000009 0000000000000000 AX 0 0 4
[15] .rodata PROGBITS 000000000013a9e0 0013a9e0
0000000000008258 0000000000000000 A 0 0 32
[16] .stapsdt.base PROGBITS 0000000000142c38 00142c38
0000000000000001 0000000000000000 A 0 0 1
[17] .eh_frame_hdr PROGBITS 0000000000142c3c 00142c3c
0000000000007714 0000000000000000 A 0 0 4
[18] .eh_frame PROGBITS 000000000014a350 0014a350
000000000002717c 0000000000000000 A 0 0 8
[19] .gcc_except_table PROGBITS 00000000001714cc 001714cc
0000000000006356 0000000000000000 A 0 0 4
[20] .tbss NOBITS 0000000000378318 00178318
0000000000000020 0000000000000000 WAT 0 0 8
[21] .init_array INIT_ARRAY 0000000000378318 00178318
0000000000000058 0000000000000000 WA 0 0 8
[22] .fini_array FINI_ARRAY 0000000000378370 00178370
0000000000000008 0000000000000000 WA 0 0 8
[23] .jcr PROGBITS 0000000000378378 00178378
0000000000000008 0000000000000000 WA 0 0 8
[24] .data.rel.ro PROGBITS 0000000000378380 00178380
00000000000089c8 0000000000000000 WA 0 0 32
[25] .dynamic DYNAMIC 0000000000380d48 00180d48
0000000000000220 0000000000000010 WA 4 0 8
[26] .got PROGBITS 0000000000380f68 00180f68
0000000000001098 0000000000000008 WA 0 0 8
[27] .got.plt PROGBITS 0000000000382000 00182000
00000000000019b8 0000000000000008 WA 0 0 8
[28] .data PROGBITS 00000000003839c0 001839c0
0000000000000178 0000000000000000 WA 0 0 32
[29] .bss NOBITS 0000000000383b40 00183b38
0000000000003720 0000000000000000 WA 0 0 32
[30] .note.stapsdt NOTE 0000000000000000 00183b38
00000000000000ec 0000000000000000 0 0 4
[31] .gnu_debuglink PROGBITS 0000000000000000 00183c24
0000000000000020 0000000000000000 0 0 4
[32] .shstrtab STRTAB 0000000000000000 00183c44
000000000000013c 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000177822 0x0000000000177822 R E 200000
LOAD 0x0000000000178318 0x0000000000378318 0x0000000000378318
0x000000000000b820 0x000000000000ef48 RW 200000
DYNAMIC 0x0000000000180d48 0x0000000000380d48 0x0000000000380d48
0x0000000000000220 0x0000000000000220 RW 8
NOTE 0x0000000000000200 0x0000000000000200 0x0000000000000200
0x0000000000000024 0x0000000000000024 R 4
TLS 0x0000000000178318 0x0000000000378318 0x0000000000378318
0x0000000000000000 0x0000000000000020 R 8
GNU_EH_FRAME 0x0000000000142c3c 0x0000000000142c3c 0x0000000000142c3c
0x0000000000007714 0x0000000000007714 R 4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 10
GNU_RELRO 0x0000000000178318 0x0000000000378318 0x0000000000378318
0x0000000000009ce8 0x0000000000009ce8 R 1
Section to Segment mapping:
Segment Sections...
00 .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_d .gnu.version_r .rela.dyn .rela.plt .init .plt .plt.got .text .fini .rodata .stapsdt.base .eh_frame_hdr .eh_frame .gcc_except_table
01 .init_array .fini_array .jcr .data.rel.ro .dynamic .got .got.plt .data .bss
02 .dynamic
03 .note.gnu.build-id
04 .tbss
05 .eh_frame_hdr
06
07 .init_array .fini_array .jcr .data.rel.ro .dynamic .got
=====
|
|
From: Paul F. <pj...@wa...> - 2018-02-12 20:42:02
|
Hi John My first attempt to post the output failed as it was too long. Here it is on a paste site https://zerobin.net/?0bf6ea80afca0924#PT/yP+KTPOXYx/+IKUC+wwhm/UCF+S2fccpHQB9Cf7Q= Here's an extract: ELF Header: Magic: 7f 45 4c 46 01 01 01 06 01 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - Solaris ABI Version: 1 Type: DYN (Shared object file) Machine: Intel 80386 Version: 0x1 Entry point address: 0x0 Start of program headers: 52 (bytes into file) Start of section headers: 12459088 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 5 Size of section headers: 40 (bytes) Number of section headers: 2202 Section header string table index: 2201 Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .dynamic DYNAMIC 000000d4 0000d4 0001a8 08 A 7 0 4 [ 2] .eh_frame_hdr PROGBITS 0000027c 00027c 006584 00 A 0 0 4 [ 3] .SUNW_syminfo VERDEF 00006800 006800 005508 04 AI 6 1 4 [ 4] .hash HASH 0000bd08 00bd08 00aa14 04 A 6 0 4 [ 5] .SUNW_ldynsym LOOS+ffffff3 0001671c 01671c 004f30 10 A 7 1267 4 [ 6] .dynsym DYNSYM 0001b64c 01b64c 015420 10 A 7 2 4 [ 7] .dynstr STRTAB 00030a6c 030a6c 0505de 00 AS 0 0 1 [ 8] .SUNW_version VERNEED 0008104c 08104c 000110 01 A 7 4 4 [ 9] .SUNW_version VERDEF 0008115c 08115c 00059c 01 A 7 41 4 [10] .SUNW_versym VERSYM 000816f8 0816f8 002a84 02 A 6 0 4 [11] .SUNW_dynsymsort LOOS+ffffff1 0008417c 08417c 006344 04 A 5 0 4 [12] .SUNW_dyntlssort LOOS+ffffff2 0008a4c0 08a4c0 000008 04 A 5 0 4 [13] .SUNW_reloc REL 0008a4c8 08a4c8 007b40 08 A 6 0 4 [14] .rel.plt REL 00092008 092008 001a80 08 AI 6 1970 4 [15] .rodata._ZNKSt10l PROGBITS 00093a88 093a88 000010 01 AMS 0 0 1 ... [669] .rodata._ZNSt7__c PROGBITS 0009b2dc 09b2dc 00002a 01 AMS 0 0 4 [670] .rodata._ZNSt7__c PROGBITS 0009b308 09b308 00002a 01 AMS 0 0 4 [671] .plt PROGBITS 0009b334 09b334 003510 10 AX 0 0 4 [672] .text PROGBITS 0009e850 09e850 0a7cb5 00 AX 0 0 16 [673] .init PROGBITS 00146510 146510 00001d 00 AX 0 0 16 [674] .fini PROGBITS 00146530 146530 000018 00 AX 0 0 16 [675] .text.unlikely._Z PROGBITS 00146548 146548 000090 00 AX 0 0 2 [676] .text._ZNSi6ignor PROGBITS 001465e0 1465e0 0001d2 00 AX 0 0 16 [677] .text.unlikely._Z PROGBITS 001467b2 1467b2 000090 00 AX 0 0 2 [678] .text._ZNSt13basi PROGBITS 00146850 146850 0001c8 00 AX 0 0 16 ... [2189] .bss._ZGVZN12_GLO NOBITS 001db090 1cb090 000008 00 WA 0 0 8 [2190] .symtab SYMTAB 00000000 1c8830 028690 10 2191 4905 4 [2191] .strtab STRTAB 00000000 1f0ec0 055620 00 S 0 0 1 [2192] .comment PROGBITS 00000000 2464e0 000099 01 MS 0 0 1 [2193] .debug_frame PROGBITS 00000000 24657c 04dda0 00 0 0 4 [2194] .debug_info PROGBITS 00000000 29431c 493301 00 0 0 1 [2195] .debug_abbrev PROGBITS 00000000 72761d 047d97 00 0 0 1 [2196] .debug_loc PROGBITS 00000000 76f3b4 1a238a 00 0 0 1 [2197] .debug_aranges PROGBITS 00000000 91173e 00a390 00 0 0 1 [2198] .debug_ranges PROGBITS 00000000 91bace 06d018 00 0 0 1 [2199] .debug_line PROGBITS 00000000 988ae6 199eb2 00 0 0 1 [2200] .debug_str PROGBITS 00000000 b22998 0a3c22 01 MS 0 0 1 [2201] .shstrtab STRTAB 00000000 bc65ba 01b693 00 S 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x00000000 0x00000000 0x17b617 0x17b617 R E 0x10000 LOAD 0x17b618 0x0018b618 0x00000000 0x4d218 0x4fa80 RWE 0x10000 DYNAMIC 0x0000d4 0x000000d4 0x00000000 0x001a8 0x00000 RWE 0 TLS 0x1c8830 0x001d8830 0x00000000 0x00000 0x00010 RW 0x4 LOOS+464e550 0x00027c 0x0000027c 0x00000000 0x064dc 0x064dc R 0x4 Section to Segment mapping: Segment Sections... 00 .dynamic .eh_frame_hdr .SUNW_syminfo .hash .SUNW_ldynsym .dynsym .dynstr .SUNW_version .SUNW_version .SUNW_versym .SUNW_dynsymsort .SUNW_dyntlssort .SUNW_reloc .rel.plt .rodata._ZNKSt10lock_error4whatEv.str1.1 .rodata._ZNKSt12_GLOBAL__N_122generic_error_category4nameEv.str1.1 .rodata._ZNKSt12_GLOBAL__N_121system_error_category4nameEv.str1.1 ... A+ Paul > Message du 11/02/18 22:40 > De : "John Reiser" > A : val...@li... > Copie à : > Objet : Re: [Valgrind-users] rodata warning > > >>> --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). >> What does >> readelf --headers .../libstdc++.so.6.0.25 >> say about the ElfXX_Shdrs and ElfXX_Phdrs, >> and the mapping of the Shdrs into the Phdrs ? > I don’t see any Elf hdrs as above in the output. Here is the output on Linux. Is there something equivalent on Solaris? ====== $ readelf --headers /lib64/libstdc++.so.6 ELF Header: Magic: 7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - GNU ABI Version: 0 Type: DYN (Shared object file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x8b880 Start of program headers: 64 (bytes into file) Start of section headers: 1588608 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 8 Size of section headers: 64 (bytes) Number of section headers: 33 Section header string table index: 32 Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0 [ 1] .note.gnu.build-i NOTE 0000000000000200 00000200 0000000000000024 0000000000000000 A 0 0 4 [ 2] .gnu.hash GNU_HASH 0000000000000228 00000228 0000000000008410 0000000000000000 A 3 0 8 [ 3] .dynsym DYNSYM 0000000000008638 00008638 00000000000205e0 0000000000000018 A 4 3 8 [ 4] .dynstr STRTAB 0000000000028c18 00028c18 0000000000040f7f 0000000000000000 A 0 0 1 [ 5] .gnu.version VERSYM 0000000000069b98 00069b98 0000000000002b28 0000000000000002 A 3 0 2 [ 6] .gnu.version_d VERDEF 000000000006c6c0 0006c6c0 000000000000050c 0000000000000000 A 4 37 8 [ 7] .gnu.version_r VERNEED 000000000006cbd0 0006cbd0 0000000000000100 0000000000000000 A 4 4 8 [ 8] .rela.dyn RELA 000000000006ccd0 0006ccd0 0000000000016aa0 0000000000000018 A 3 0 8 [ 9] .rela.plt RELA 0000000000083770 00083770 0000000000004ce0 0000000000000018 AI 3 27 8 [10] .init PROGBITS 0000000000088450 00088450 0000000000000017 0000000000000000 AX 0 0 4 [11] .plt PROGBITS 0000000000088470 00088470 0000000000003350 0000000000000010 AX 0 0 16 [12] .plt.got PROGBITS 000000000008b7c0 0008b7c0 00000000000000b8 0000000000000000 AX 0 0 8 [13] .text PROGBITS 000000000008b880 0008b880 00000000000af149 0000000000000000 AX 0 0 16 [14] .fini PROGBITS 000000000013a9cc 0013a9cc 0000000000000009 0000000000000000 AX 0 0 4 [15] .rodata PROGBITS 000000000013a9e0 0013a9e0 0000000000008258 0000000000000000 A 0 0 32 [16] .stapsdt.base PROGBITS 0000000000142c38 00142c38 0000000000000001 0000000000000000 A 0 0 1 [17] .eh_frame_hdr PROGBITS 0000000000142c3c 00142c3c 0000000000007714 0000000000000000 A 0 0 4 [18] .eh_frame PROGBITS 000000000014a350 0014a350 000000000002717c 0000000000000000 A 0 0 8 [19] .gcc_except_table PROGBITS 00000000001714cc 001714cc 0000000000006356 0000000000000000 A 0 0 4 [20] .tbss NOBITS 0000000000378318 00178318 0000000000000020 0000000000000000 WAT 0 0 8 [21] .init_array INIT_ARRAY 0000000000378318 00178318 0000000000000058 0000000000000000 WA 0 0 8 [22] .fini_array FINI_ARRAY 0000000000378370 00178370 0000000000000008 0000000000000000 WA 0 0 8 [23] .jcr PROGBITS 0000000000378378 00178378 0000000000000008 0000000000000000 WA 0 0 8 [24] .data.rel.ro PROGBITS 0000000000378380 00178380 00000000000089c8 0000000000000000 WA 0 0 32 [25] .dynamic DYNAMIC 0000000000380d48 00180d48 0000000000000220 0000000000000010 WA 4 0 8 [26] .got PROGBITS 0000000000380f68 00180f68 0000000000001098 0000000000000008 WA 0 0 8 [27] .got.plt PROGBITS 0000000000382000 00182000 00000000000019b8 0000000000000008 WA 0 0 8 [28] .data PROGBITS 00000000003839c0 001839c0 0000000000000178 0000000000000000 WA 0 0 32 [29] .bss NOBITS 0000000000383b40 00183b38 0000000000003720 0000000000000000 WA 0 0 32 [30] .note.stapsdt NOTE 0000000000000000 00183b38 00000000000000ec 0000000000000000 0 0 4 [31] .gnu_debuglink PROGBITS 0000000000000000 00183c24 0000000000000020 0000000000000000 0 0 4 [32] .shstrtab STRTAB 0000000000000000 00183c44 000000000000013c 0000000000000000 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), l (large) I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000177822 0x0000000000177822 R E 200000 LOAD 0x0000000000178318 0x0000000000378318 0x0000000000378318 0x000000000000b820 0x000000000000ef48 RW 200000 DYNAMIC 0x0000000000180d48 0x0000000000380d48 0x0000000000380d48 0x0000000000000220 0x0000000000000220 RW 8 NOTE 0x0000000000000200 0x0000000000000200 0x0000000000000200 0x0000000000000024 0x0000000000000024 R 4 TLS 0x0000000000178318 0x0000000000378318 0x0000000000378318 0x0000000000000000 0x0000000000000020 R 8 GNU_EH_FRAME 0x0000000000142c3c 0x0000000000142c3c 0x0000000000142c3c 0x0000000000007714 0x0000000000007714 R 4 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 10 GNU_RELRO 0x0000000000178318 0x0000000000378318 0x0000000000378318 0x0000000000009ce8 0x0000000000009ce8 R 1 Section to Segment mapping: Segment Sections... 00 .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_d .gnu.version_r .rela.dyn .rela.plt .init .plt .plt.got .text .fini .rodata .stapsdt.base .eh_frame_hdr .eh_frame .gcc_except_table 01 .init_array .fini_array .jcr .data.rel.ro .dynamic .got .got.plt .data .bss 02 .dynamic 03 .note.gnu.build-id 04 .tbss 05 .eh_frame_hdr 06 07 .init_array .fini_array .jcr .data.rel.ro .dynamic .got ===== ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: John R. <jr...@bi...> - 2018-02-13 00:03:25
|
> https://zerobin.net/?0bf6ea80afca0924#PT/yP+KTPOXYx/+IKUC+wwhm/UCF+S2fccpHQB9Cf7Q= [That "paste" site says that the page expires in 6 days.] Looking at the dumped data, I see three Elf32_Shdr Sections named ".rodata": [18] .rodata PROGBITS 00093ac0 093ac0 003504 00 A 0 0 32 [28] .rodata PROGBITS 000970ac 0970ac 0002b4 01 AMS 0 0 4 [41] .rodata PROGBITS 00098a97 098a97 0001a9 01 AMS 0 0 1 while the valgrind code in coregrind/m_debuginfo/readelf.c subroutine Bool ML_(read_elf_debug_info) ( struct _DebugInfo* di ) appears to assume that there will be only one such ".rodata": if (0 == VG_(strcmp)(name, ".rodata")) { if (inrx && !di->rodata_present) { \\\ only di->rodata_present = True; /// once? di->rodata_svma = svma; di->rodata_avma = svma + inrx->bias; di->rodata_size = size; di->rodata_bias = inrx->bias; di->rodata_debug_svma = svma; di->rodata_debug_bias = inrx->bias; /* NB was 'inrw' prior to r11794 */ TRACE_SYMTAB("acquiring .rodata svma = %#lx .. %#lx\n", di->rodata_svma, di->rodata_svma + di->rodata_size - 1); TRACE_SYMTAB("acquiring .rodata avma = %#lx .. %#lx\n", di->rodata_avma, di->rodata_avma + di->rodata_size - 1); TRACE_SYMTAB("acquiring .rodata bias = %#lx\n", (UWord)di->rodata_bias); } else { BAD(".rodata"); } } It might be possible to confirm this diagnosis by turning on TRACE_SYMTAB (which is controlled by command-line argument --trace-symtab=yes and perhaps by --trace-symtab-patt=<patt> ) and looking through what valgrind reports. [Of course I also see the many hundreds of Sections ".rodata.<subr_name>" and ".text.<subr_name>" and ".text.unlikely.<subr_name>" which at first glance seem to be overkill and/or extravagant waste of space. There should be a more-compact way to convey the information.] |
|
From: John R. <jr...@bi...> - 2018-02-13 02:54:02
|
It appears that all the .rodata* sections are contiguous, after considering alignment. Thus a workaround would be for valgrind's debuginfo reader to aggregate them all into one internal .rodata which is the convex hull. Example: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al round_up(Off + Size, Al.next) = Off.next [15] .rodata._ZNKSt10l PROGBITS 00093a88 093a88 000010 01 AMS 0 0 1 round_up(093a88 + 000010, 1) = 093a98 [16] .rodata._ZNKSt12_ PROGBITS 00093a98 093a98 000008 01 AMS 0 0 1 round_up(093a98 + 000008, 1) = 093aa0 [17] .rodata._ZNKSt12_ PROGBITS 00093aa0 093aa0 000007 01 AMS 0 0 1 round_up(093aa0 + 000007, 32) = 093ac0 <<< note Al.next [18] .rodata PROGBITS 00093ac0 093ac0 003504 00 A 0 0 32 round_up(093ac0 + 003504, 32) = 096fe0 [19] .rodata._ZTSNSt12 PROGBITS 00096fe0 096fe0 00002c 00 A 0 0 32 round_up(096fe0 + 00002c, 32) = 097020 [20] .rodata._ZTSNSt12 PROGBITS 00097020 097020 00002b 00 A 0 0 32 round_up(097020 + 00002b, 1) = 09704b <<< note Al.next [21] .rodata._ZNSt6chr PROGBITS 0009704b 09704b 000001 00 A 0 0 1 |
|
From: Paul F. <pj...@wa...> - 2018-02-13 08:22:34
|
> On 13 Feb 2018, at 01:03, John Reiser <jr...@bi...> wrote: > >> https://zerobin.net/?0bf6ea80afca0924#PT/yP+KTPOXYx/+IKUC+wwhm/UCF+S2fccpHQB9Cf7Q= > > [That "paste" site says that the page expires in 6 days.] It’s the first time I’ve used such a site. I don’t know if there are ones that have free persistent storage for large files. ... > It might be possible to confirm this diagnosis by turning on TRACE_SYMTAB > (which is controlled by command-line argument --trace-symtab=yes > and perhaps by --trace-symtab-patt=<patt> ) and looking through > what valgrind reports. > > [Of course I also see the many hundreds of Sections ".rodata.<subr_name>" > and ".text.<subr_name>" and ".text.unlikely.<subr_name>" which at first > glance seem to be overkill and/or extravagant waste of space. There > should be a more-compact way to convey the information.] I did try —trace-symtab=yes, but the output was exceedingly long. I’ll give the pattern a try tonight. On the other front, I’ll try to find out why libstc++ has so many sections. A+ Paul |
|
From: John R. <jr...@bi...> - 2018-02-15 23:07:19
|
> --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 is in the "do not forget about this situation" list as: https://bugs.kde.org/show_bug.cgi?id=353802 "ELF debug info reader confused with multiple .rodata sections" The bug Status currently is incorrect. It says "RESOLVED FIXED". However the original patch to fix it was reverted without changing the status: https://bugs.kde.org/show_bug.cgi?id=353802#c9 That was almost 2 years ago, and anyway does not include this week's re-appearance. I could find no way to remove the "RESOLVED FIXED" label. |
|
From: Ivo R. <iv...@iv...> - 2018-02-16 07:02:15
|
2018-02-15 15:54 GMT+01:00 John Reiser <jr...@bi...>: >> --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 is in the "do not forget about this situation" list as: > https://bugs.kde.org/show_bug.cgi?id=353802 > "ELF debug info reader confused with multiple .rodata sections" > > The bug Status currently is incorrect. It says "RESOLVED FIXED". > However the original patch to fix it was reverted without changing the > status: > https://bugs.kde.org/show_bug.cgi?id=353802#c9 > That was almost 2 years ago, and anyway does not include this week's > re-appearance. > > I could find no way to remove the "RESOLVED FIXED" label. What would you like to do instead? REOPENED? https://bugs.kde.org/show_bug.cgi?id=360749 explains why the "fix" was reverted back then. It was rather a kludge around Solaris linker limitation. The underlying problem with Solaris linker is different this time. Back in 2015, there was some linker development hiccup which got eventually fixed. As described in 360749, it occurred only for some period during Solaris 12 development. Recent occurrence is found in Solaris 11.3 and we do not see it with libstdc++.so.6.0.20 and gcc 5. It is only seen with gcc 8 and libstdc++.so.6.0.25. I. |
|
From: John R. <jr...@bi...> - 2018-02-16 16:27:13
|
On 02/16/2018 07:02 UTC, Ivo Raisr wrote: > 2018-02-15 15:54 GMT+01:00 John Reiser <jr...@bi...>: >>> --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 is in the "do not forget about this situation" list as: >> https://bugs.kde.org/show_bug.cgi?id=353802 >> "ELF debug info reader confused with multiple .rodata sections" >> >> The bug Status currently is incorrect. It says "RESOLVED FIXED". >> However the original patch to fix it was reverted without changing the >> status: >> https://bugs.kde.org/show_bug.cgi?id=353802#c9 >> That was almost 2 years ago, and anyway does not include this week's >> re-appearance. >> >> I could find no way to remove the "RESOLVED FIXED" label. > What would you like to do instead? REOPENED? The presenting symptom is the same, so REOPENED is an obvious candidate. My post was to draw attention to the re-appearance because I could not change the Status away from "no need to look at this anymore." Another way would be to create a new bug report. > > https://bugs.kde.org/show_bug.cgi?id=360749 > explains why the "fix" was reverted back then. > It was rather a kludge around Solaris linker limitation. > > The underlying problem with Solaris linker is different this time. > Back in 2015, there was some linker development hiccup which got > eventually fixed. > As described in 360749, it occurred only for some period during > Solaris 12 development. > > Recent occurrence is found in Solaris 11.3 and we do not see it with > libstdc++.so.6.0.20 and gcc 5. > It is only seen with gcc 8 and libstdc++.so.6.0.25. The resolution of 360749 says Solaris linker now combines SHF_STRINGS SHF_MERGE sections with differing alignment and thus creates only one .rodata section. The Sample in 353802 shows a different kind of "multiple .rodata": one .rodata with SHF_MERGE|SHF_STRINGS, one without, and many .rodata.<subr_name> with SHF_MERGE|SHF_STRINGS. All are contiguous after considering alignment. It seems to me that the re-appearance of the symptom is caused by the same old problem. Solaris linker (and/or its input linker script) is prone to not merging Sections that coregrind's debuginfo reader would rather consider as one instead of many. So coregrind should be extended to handle multiple .rodata*, or the reader should work-around the problem by looking for and doing the merge itself. There is also the question "Why does coregrind care?" In this case it seems that the refinement of the read-only data intervals carries no information that matters to coregrind, so the complaint is at most about the time wasted in processing the descriptors. |
|
From: Ivo R. <iv...@iv...> - 2018-02-28 04:23:15
|
2018-02-16 17:27 GMT+01:00 John Reiser <jr...@bi...>: >> What would you like to do instead? REOPENED? > > > The presenting symptom is the same, so REOPENED is an obvious candidate. > My post was to draw attention to the re-appearance because I > could not change the Status away from "no need to look at this anymore." > Another way would be to create a new bug report. I'd prefer another bug report in this case. Although the symptoms are equivalent, the underlying reasoning is different. And the new bug will have different story, uncluttered by the past. >> https://bugs.kde.org/show_bug.cgi?id=360749 >> explains why the "fix" was reverted back then. >> It was rather a kludge around Solaris linker limitation. >> >> The underlying problem with Solaris linker is different this time. >> Back in 2015, there was some linker development hiccup which got >> eventually fixed. >> As described in 360749, it occurred only for some period during >> Solaris 12 development. >> >> Recent occurrence is found in Solaris 11.3 and we do not see it with >> libstdc++.so.6.0.20 and gcc 5. >> It is only seen with gcc 8 and libstdc++.so.6.0.25. > > > The resolution of 360749 says > Solaris linker now combines SHF_STRINGS SHF_MERGE sections with differing > alignment and thus creates only one .rodata section. > > The Sample in 353802 shows a different kind of "multiple .rodata": > one .rodata with SHF_MERGE|SHF_STRINGS, one without, and many > .rodata.<subr_name> with SHF_MERGE|SHF_STRINGS. All are contiguous > after considering alignment. > > It seems to me that the re-appearance of the symptom is caused by > the same old problem. Solaris linker (and/or its input linker script) > is prone to not merging Sections that coregrind's debuginfo reader > would rather consider as one instead of many. > So coregrind should be extended to handle multiple .rodata*, or the reader > should work-around the problem by looking for and doing the merge itself. > > There is also the question "Why does coregrind care?" In this case > it seems that the refinement of the read-only data intervals carries > no information that matters to coregrind, so the complaint is at most > about the time wasted in processing the descriptors. Indeed. Although one .rodata is arguable the preferred outcome, it should not matter. As long as the ELF file is properly formatted, and all the .rodata sections actually end up in the text segment, the specific sections within that segment that they're assigned to is of little consequence. Unfortunately the Valgrind debug info reader assumes one .rodata (going from section name to symbols). This is a wrong approach. The right approach is to follow the shndx from the symbol to the correct section. I. |
|
From: John R. <jr...@bi...> - 2018-02-21 21:55:23
|
On 02/19/2018 09:35 UTC, Ivo Raisr wrote: > I'd prefer another bug report in this case. > Although the symptoms are equivalent, the underlying reasoning is different. > And the new bug will have different story, uncluttered by the past. https://bugs.kde.org/show_bug.cgi?id=390871 |
|
From: Ivo R. <iv...@iv...> - 2018-02-22 07:00:09
|
2018-02-21 22:55 GMT+01:00 John Reiser <jr...@bi...>: > On 02/19/2018 09:35 UTC, Ivo Raisr wrote: > >> I'd prefer another bug report in this case. >> Although the symptoms are equivalent, the underlying reasoning is >> different. >> And the new bug will have different story, uncluttered by the past. > > > https://bugs.kde.org/show_bug.cgi?id=390871 Thank you, I. |