https://bugs.kde.org/show_bug.cgi?id=390871
--- Comment #2 from Paul Floyd <pa...@free.fr> --- Mail from Rainer Orth on GCC mailing list 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 -- You are receiving this mail because: You are watching all bug changes.
