* Solaris issues
@ 2018-06-02 10:29 Paul Floyd
2018-06-03 21:35 ` Jonathan Wakely
2018-06-04 14:46 ` Rainer Orth
0 siblings, 2 replies; 10+ messages in thread
From: Paul Floyd @ 2018-06-02 10:29 UTC (permalink / raw)
To: gcc
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Solaris issues
2018-06-02 10:29 Solaris issues Paul Floyd
@ 2018-06-03 21:35 ` Jonathan Wakely
2018-06-04 14:50 ` Rainer Orth
2018-06-04 14:46 ` Rainer Orth
1 sibling, 1 reply; 10+ messages in thread
From: Jonathan Wakely @ 2018-06-03 21:35 UTC (permalink / raw)
To: Paul Floyd; +Cc: gcc
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?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Solaris issues
2018-06-03 21:35 ` Jonathan Wakely
@ 2018-06-04 14:50 ` Rainer Orth
2018-06-04 18:25 ` Paul Floyd
0 siblings, 1 reply; 10+ messages in thread
From: Rainer Orth @ 2018-06-04 14:50 UTC (permalink / raw)
To: Jonathan Wakely; +Cc: Paul Floyd, gcc
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Solaris issues
2018-06-04 14:50 ` Rainer Orth
@ 2018-06-04 18:25 ` Paul Floyd
2018-06-05 13:07 ` Rainer Orth
0 siblings, 1 reply; 10+ messages in thread
From: Paul Floyd @ 2018-06-04 18:25 UTC (permalink / raw)
To: gcc
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Solaris issues
2018-06-04 18:25 ` Paul Floyd
@ 2018-06-05 13:07 ` Rainer Orth
2018-06-05 20:36 ` paulf
0 siblings, 1 reply; 10+ messages in thread
From: Rainer Orth @ 2018-06-05 13:07 UTC (permalink / raw)
To: Paul Floyd; +Cc: gcc
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Solaris issues
2018-06-05 13:07 ` Rainer Orth
@ 2018-06-05 20:36 ` paulf
2018-06-06 2:42 ` Rainer Orth
0 siblings, 1 reply; 10+ messages in thread
From: paulf @ 2018-06-05 20:36 UTC (permalink / raw)
To: gcc
----- 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Solaris issues
2018-06-05 20:36 ` paulf
@ 2018-06-06 2:42 ` Rainer Orth
0 siblings, 0 replies; 10+ messages in thread
From: Rainer Orth @ 2018-06-06 2:42 UTC (permalink / raw)
To: paulf; +Cc: gcc
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Solaris issues
2018-06-02 10:29 Solaris issues Paul Floyd
2018-06-03 21:35 ` Jonathan Wakely
@ 2018-06-04 14:46 ` Rainer Orth
2018-06-04 20:02 ` paulf
1 sibling, 1 reply; 10+ messages in thread
From: Rainer Orth @ 2018-06-04 14:46 UTC (permalink / raw)
To: Paul Floyd; +Cc: gcc
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Solaris issues
@ 2018-06-04 10:07 paulf
0 siblings, 0 replies; 10+ messages in thread
From: paulf @ 2018-06-04 10:07 UTC (permalink / raw)
To: Jonathan Wakely; +Cc: gcc
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?
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2018-06-05 20:36 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-02 10:29 Solaris issues Paul Floyd
2018-06-03 21:35 ` Jonathan Wakely
2018-06-04 14:50 ` Rainer Orth
2018-06-04 18:25 ` Paul Floyd
2018-06-05 13:07 ` Rainer Orth
2018-06-05 20:36 ` paulf
2018-06-06 2:42 ` Rainer Orth
2018-06-04 14:46 ` Rainer Orth
2018-06-04 20:02 ` paulf
2018-06-04 10:07 paulf
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).