[Dwarf-Discuss] Interaction between aranges and unit proposals

[Mark Wielaard]

Hi Tom,

On Wed, 2014-04-23 at 09:01 -0600, Tom Tromey wrote:
> Mark> To make it possible to quickly see whether an address (range) is covered
> Mark> by an ELF file containing DWARF information two proposals were made:
> 
> I finally read through this thread.
> 
> Cary> I think it's fine for a consumer to first assume that the
> Cary> .debug_aranges table is complete, but if an address lookup fails, then
> Cary> it can scan the .debug_info section, hopping from one CU/TU to the
> Cary> next, looking for CUs that aren't covered by .debug_aranges tables.
> Cary> Having the debug_info length field in the aranges table would help,
> Cary> but even then, it's not clear to me how much it will help.
> 
> The idea was to avoid having to scan all the CUs just because a bad
> address was given.
> 
> However, the completeness property is probably more important for
> by-name indices, where you don't want a single typo to destroy whatever
> performance gain you get from an index.

That depends on whether you assume bad addresses won't normally happen
and won't cause regeneration of the index. Sadly it seems that while
debugging (seeing a bad or unitialized function pointer), or sometimes
even when trying to produce a simple backtrace (you'll need the DWARF
info to show inlines) you do often get addresses that might point to
something random. What do you do then if you cannot rely on the
completeness or correctness of the aranges table?

> That said, on the whole I think it's probably fine to drop this
> proposal.  While this remains a bit of a hole in DWARF, in practice we
> run dwz on everything in the distro and it can fix up issues like this.

I don't think that is a good idea. dwz is a really great tool. But it
only works for "production" debug info. It won't be used for the common
edit-compile-debug cycle of your program that isn't packaged and in
production yet. When used as a DWARF compressor that just represent the
same information just in a smaller way I think dwz is perfect. But if
users would need to run it to fix up the produced DWARF then I think we
are better off fixing the original DWARF producers.

What I am really trying to avoid is having to ship duplicate aranges
information. Once in standard DWARF .debug_aranges and then again (but
more complete) in .gdb_index. If that is necessary to efficiently use
GDB then I feel we need to fix the .debug_aranges specification.

Thanks,

Mark