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