Handle all new DW_LLE opcodes in .debug_loclists in dwarf_getlocation.
__libdw_read_begin_end_pair_inc now also handles a default location
(which is simply the range [0,-1]). Since expression blocks can now
also come from the .debug_loclists section add a new fake_loclists_cu
necessary for checking
On Thu, 2018-05-24 at 21:08 +0200, Mark Wielaard wrote:
> Handle all new DW_RLE opcodes in .debug_rnglists in dwarf_ranges. Extract
> code for reading .debug_addr indexes from dwarf_formaddr as __libdw_addrx
> to reuse in __libdw_read_begin_end_pair_inc. And add new testcase.
Pushed this to master
Add debug-dump=addr which will show the .debug_addr section tables.
The only tricky bit is the fact that GNU DebugFission, a DWARF4
extension, didn't produce unit table headers. So if we see a mixed
DWARF4/5 .debug_addr table we have to reconstruct the table length
from the CU DIE DW_AT_[GNU_]_addr
The .debug_str_offsets tables are indirect string offsets into the
.debug_str section. For DWARF5 they can be in both the main, skeleton
and split dwarf (.dwo) files.
For DWARF4 with the GNU DebugFission extension the tables will not have
an header and they will only be in the split DWARF (.dwo) f
On Fri, 2018-05-25 at 14:43 +0200, Mark Wielaard wrote:
> To get the right context (especially addresses) when looking at a .dwo file
> we really need the skeleton file. If we can find it (simply replace .dwo
> with .o) then use that to get to the split DWARF units so that libdw sets
> up all rele
Found by valgrind when trying to match a split unit from a .dwo file
that doesn't contain the split unit (as first) match. We would close
the split Dwarf too early, before we had inspected all units in it.
Add a testcase that simulates this. Which failed (at least under valgrind
as run by make dis
