Base address specifier in debug_loc.dwo

[David Blaikie <dblaikie at gmail dot com>]

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.  */
      if (baton->from_dwo)
        {
          low += base_offset;
          high += base_offset;
        }
      else
        {
          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
added, right?
& 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)