https://bugs.kde.org/show_bug.cgi?id=395682
Mark Wielaard <m...@klomp.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Reading debug info |Reading debug info of
| |binaries linked with
| |binutils ld -z
| |separate-code
CC| |m...@klomp.org
--- Comment #4 from Mark Wielaard <m...@klomp.org> ---
The root cause is that ld -z separate-code introduces various new PT_LOAD
segments and the code in valgrind interpreting the PT_LOAD mappings is very
specific about what is does and what it doesn't consider a code or data mapping
to match symbols and debuginfo against.
There are various bugs for this:
fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1600034
debian: http://bugs.debian.org/903389
binutils: https://sourceware.org/bugzilla/show_bug.cgi?id=23357
The following valgrind bug is also somewhat related:
https://bugs.kde.org/show_bug.cgi?id=390871 "ELF debug info reader confused
with multiple .rodata* sections"
The issue can most easily be seen using --trace-symtab=yes which will show the
PT_LOAD program headers and flags.
There are two places in the code which interpret the mappings/flags and try to
map things to debuginfo.
coregrind/m_debuginfo/debuginfo.c (di_notify_mmap) and
coregrind/m_debuginfo/readelf.c (read_elf_debug_info)
Note in the first that it doesn't set up is_ro_map unless compiled for darwin.
Note in the second that it seems to only consider the first PT_LOAD segment and
bails out when that doesn't match.
--
You are receiving this mail because:
You are watching all bug changes.
