Solaris issues

Solaris issues

[Paul Floyd]

Hi

I’ve been having 2 issues with GCC head on Solaris. Firstly. The build is currently broken

gmake[3]: Leaving directory `/export/home/paulf/scratch/gcc/build'
Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
Bootstrap comparison failure!
i386-pc-solaris2.11/amd64/libgcc/avx_resms64_s.o differs
i386-pc-solaris2.11/amd64/libgcc/sse_resms64_s.o differs
i386-pc-solaris2.11/amd64/libgcc/sse_resms64.o differs
[more snipped]

Is there any workaround for this

Secondly I’ve been doing some work on adding support for C++14 and C++17 sized/aligned new and delete operators.

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>)

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>
The above patch does fix the problem.
Any idea why so many sections are getting generated? (The test case is trivially small)

A+
Paul

Re: Solaris issues

[Jonathan Wakely]

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?

Re: Solaris issues

[Rainer Orth]

Hi Paul,

> I’ve been having 2 issues with GCC head on Solaris. Firstly. The build is currently broken
>
> gmake[3]: Leaving directory `/export/home/paulf/scratch/gcc/build'
> Comparing stages 2 and 3
> warning: gcc/cc1obj-checksum.o differs
> Bootstrap comparison failure!
> i386-pc-solaris2.11/amd64/libgcc/avx_resms64_s.o differs
> i386-pc-solaris2.11/amd64/libgcc/sse_resms64_s.o differs
> i386-pc-solaris2.11/amd64/libgcc/sse_resms64.o differs
> [more snipped]
>
> Is there any workaround for this

this is PR target/85994.  For the moment, you can just touch compare and
resume the build.  Trivial patch forthcoming...

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Solaris issues

[Rainer Orth]

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.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Solaris issues

[Paul Floyd]

> 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

Re: Solaris issues

[paulf]

----- Original Message -----
> Hi Paul,
> 

[Build issue on Solaris]

> 
> this is PR target/85994.  For the moment, you can just touch compare
> and
> resume the build.  Trivial patch forthcoming...

Hi Rainer

This worked a treat, thanks.

A+
Paul

Re: Solaris issues

[Rainer Orth]

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

Re: Solaris issues

[paulf]

----- Original Message -----
> Hi Paul,

[snip - lots of .rodata sections]
 
> 
> 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.

I am indeed using Solaris ld - configured with "--without-gnu-ld --with-ld=/usr/ccs/bin/ld"


> 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

I'll have a look. I probably read an older version in the distant past.

> (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

Hmm OK. Do you know what change caused this?

Since there's a patch for Valgrind to fix it, it looks like that would be the best solution.

A+
Paul

Re: Solaris issues

[Rainer Orth]

Hi Paul,

>> 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
>
> Hmm OK. Do you know what change caused this?

what change to what?  ld, libstdc++, ...?  I see those multiple
.rodata.* sections as far back as the /usr/sfw/lib/libstdc++.so bundled
in Solaris 10.

> Since there's a patch for Valgrind to fix it, it looks like that would be
> the best solution.

Certainly: besides there's no reason for any artificial limit like it
currently has, they cannot expect everyone to upgrade to Solaris 11.4
once it's released.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Solaris issues

[paulf]

Hi

That should be 'adding to valgrind' which I mentioned in the following paragraph.

A+
Paul





-------- Original message --------
From: Jonathan Wakely <jwakely.gcc@gmail.com> 
Date:2018/06/03  23:34  (GMT+01:00) 
To: Paul Floyd <paulf@free.fr> 
Cc: gcc@gcc.gnu.org 
Subject: Re: Solaris issues 

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?