2018-02-16 17:27 GMT+01:00 John Reiser <jrei...@bitwagon.com>: >> What would you like to do instead? REOPENED? > > > The presenting symptom is the same, so REOPENED is an obvious candidate. > My post was to draw attention to the re-appearance because I > could not change the Status away from "no need to look at this anymore." > Another way would be to create a new bug report.
I'd prefer another bug report in this case. Although the symptoms are equivalent, the underlying reasoning is different. And the new bug will have different story, uncluttered by the past. >> https://bugs.kde.org/show_bug.cgi?id=360749 >> explains why the "fix" was reverted back then. >> It was rather a kludge around Solaris linker limitation. >> >> The underlying problem with Solaris linker is different this time. >> Back in 2015, there was some linker development hiccup which got >> eventually fixed. >> As described in 360749, it occurred only for some period during >> Solaris 12 development. >> >> Recent occurrence is found in Solaris 11.3 and we do not see it with >> libstdc++.so.6.0.20 and gcc 5. >> It is only seen with gcc 8 and libstdc++.so.6.0.25. > > > The resolution of 360749 says > Solaris linker now combines SHF_STRINGS SHF_MERGE sections with differing > alignment and thus creates only one .rodata section. > > The Sample in 353802 shows a different kind of "multiple .rodata": > one .rodata with SHF_MERGE|SHF_STRINGS, one without, and many > .rodata.<subr_name> with SHF_MERGE|SHF_STRINGS. All are contiguous > after considering alignment. > > It seems to me that the re-appearance of the symptom is caused by > the same old problem. Solaris linker (and/or its input linker script) > is prone to not merging Sections that coregrind's debuginfo reader > would rather consider as one instead of many. > So coregrind should be extended to handle multiple .rodata*, or the reader > should work-around the problem by looking for and doing the merge itself. > > There is also the question "Why does coregrind care?" In this case > it seems that the refinement of the read-only data intervals carries > no information that matters to coregrind, so the complaint is at most > about the time wasted in processing the descriptors. Indeed. Although one .rodata is arguable the preferred outcome, it should not matter. As long as the ELF file is properly formatted, and all the .rodata sections actually end up in the text segment, the specific sections within that segment that they're assigned to is of little consequence. Unfortunately the Valgrind debug info reader assumes one .rodata (going from section name to symbols). This is a wrong approach. The right approach is to follow the shndx from the symbol to the correct section. I. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
