https://sourceware.org/bugzilla/show_bug.cgi?id=33723
--- Comment #1 from Kashyap Chamarthy <kchamart at redhat dot com> ---
Root case analysis (Nick Clifton)
---------------------------------
This is Nick's analysis, I'm posting it verbatim with minor formatting
edits:
What appears to be happening is that some RISC-V object files
contain "bad" relocations that are supposed to put the correct
offsets from places in the .debug_info section to strings in the
.debug_line_str section. (and possibly the .debug_str section too,
although I have not confirmed this).
I put "bad" in quotes because the relocations do actually work, but
only when the object file is examined in isolation. When the object
file is linked into an executable and the contents of the
.debug_line_str section are merged with other .debug_line_str
sections in other object files, the relocations are not updated
correctly and the result is that the executable ends up with entries
in the .debug_info section that refer to bogus offsets in the
.debug_line_str section. The reason that these relocations are "bad"
is that they reference local symbols that are placed beyond the end
of the .debug_line_str section. Such symbols are not adjusted when
the .debug_line_str section is merged, which is why things break.
To proceed we need to find out if it is the assembler that is
placing these symbols beyond the end of the .debug_line_str section,
or if it is gcc telling the assembler to place them there. For that
to happen someone needs to build a problematic object file with the
`--save-temps` option added to the `gcc` command line, and then the
assembler output from gcc needs to be examined.
--
You are receiving this mail because:
You are on the CC list for the bug.
