Solaris issues

[paulf@free.fr]

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