This is the mail archive of the
mailing list for the GDB project.
Base address specifier in debug_loc.dwo
- From: David Blaikie <dblaikie at gmail dot com>
- To: gdb at sourceware dot org
- Cc: dje <dje at google dot com>
- Date: Fri, 4 Aug 2017 16:53:36 -0700
- Subject: Base address specifier in debug_loc.dwo
- Authentication-results: sourceware.org; auth=none
I was looking to reduce object size of LLVM's split-dwarf debug info -
especially looking to reduce relocations (long term a more aggressive
solution will be needed, but short term debug_loc.dwo/loclists (&
rnglists) already support what I'm looking for).
LLVM currently produces only DW_LLE_startx_length entries in
debug_loc.dwo - this means potentially one address in debug_addr per
range in debug_loc.dwo (in some cases you might get lucky and the
address might already be there for some reason (like for the start of
a range in debug_rnglists, etc))
Instead, what I've prototyped ( https://reviews.llvm.org/D36300 ) is
to have LLVM use the first address it emits in a section (the start of
the first function with debug info - so it'll be the low_pc of that
function anyway - in a given section) as the DW_LLE_base_address, then
use DW_LLE_offset_pair relative to that.
That way it won't introduce any new entries in debug_addr (ultimately,
I'd like to get debug_addr down to the same set of addresses (+ the
address of any global variables) as debug_line - and, beyond that,
roll debug_addr into debug_line so only one relocation for each
section is needed)
Anyway - I came across this bit of code in dwarf2loc.c:
/* Otherwise, a location expression entry.
If the entry is from a DWO, don't add base address: the entry is from
.debug_addr which already has the DWARF "base address". We still add
base_offset in case we're debugging a PIE executable. */
low += base_offset;
high += base_offset;
low += base_address;
high += base_address;
Which seems incorrect to me. decode_debug_loc_dwo_addresses called
above does support returning DEBUG_LOC_BASE_ADDRESS if the
debug_loc.dwo entry kind is DW_LLE_GNU_base_address_selection_entry.
So if a base address selection entry has been seen - this should be
& even if a base address selection entry hasn't been seen - the
default base address of the unit should apply - though I guess that
wouldn't work because there aren't enough forms that should be
interpreted as address indexes from those that should be base relative
offsets... - so why is there support for base address selection
entries here if they're unusable?
Also, looking through this code - it seems like there's this half
(that's incomplete wrt the Fission proposal (
https://gcc.gnu.org/wiki/DebugFission ) and the DWARF5 spec) and
there's decode_debug_loclists_address - which /only/ supports
base_address + offset_pair (not startx_length, not base_addressx (so
can't be used with fission), etc)
Is this work in progress? Is there some consistency here I'm missing?
Is there a format I can produce from LLVM that allows reuse of an
arbitrary address that's prior to the address range being described &
that GDB understands?
(this is all a bit moot, given I'm stuck on an even older GDB - but
for Android folks, anyone else out there, since I've done the work,
I'm curious whether it can be made to be useful/usable)