This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Solaris issues



> On 4 Jun 2018, at 16:50, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote:
> 
> Hi Jonathan,
> 
>> On 2 June 2018 at 11:29, Paul Floyd <paulf@free.fr> wrote:
>>> Secondly I’ve been doing some work on adding support for C++14 and C++17
>>> sized/aligned new and delete operators.
>> 
>> Aren't they already supported? I thought Solaris had aligned_alloc
>> and/or posix_memalign?
> 
> posix_memalign had already been added in Solaris 11.0, while
> aligned_alloc followed in Solaris 11.4.
> 

That’s nothing to do with my problem.

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)


A+
Paul

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]