On 02/16/2018 07:02 UTC, Ivo Raisr wrote:
2018-02-15 15:54 GMT+01:00 John Reiser <jrei...@bitwagon.com>:
--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
(GCC SVN head, Solaris 11.3, Valgrind git head).
This is in the "do not forget about this situation" list as:
https://bugs.kde.org/show_bug.cgi?id=353802
"ELF debug info reader confused with multiple .rodata sections"
The bug Status currently is incorrect. It says "RESOLVED FIXED".
However the original patch to fix it was reverted without changing the
status:
https://bugs.kde.org/show_bug.cgi?id=353802#c9
That was almost 2 years ago, and anyway does not include this week's
re-appearance.
I could find no way to remove the "RESOLVED FIXED" label.
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.
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.
------------------------------------------------------------------------------
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
