[Dwarf-Discuss] Interaction between aranges and unit proposals

[Mark Wielaard]

On Wed, 2014-04-02 at 10:21 -0700, Cary Coutant wrote:
> > To make it possible to quickly see whether an address (range) is covered
> > by an ELF file containing DWARF information two proposals were made:
> >
> > aranges does not have debug info length
> > http://dwarfstd.org/ShowIssue.php?issue=100430.1
> >
> > debug_aranges and address-less CUs
> > http://dwarfstd.org/ShowIssue.php?issue=100430.2
> 
> We dropped the first and made the second a best practice.
> 
> > But then there are also the following proposals:
> >
> > Type Unit Merge
> > http://dwarfstd.org/ShowIssue.php?issue=130526.1
> 
> Yes, this is pretty much why we dropped the first proposal.

It isn't marked as dropped BTW. The status is open with you as champion.

> > Ambiguity in DWARF4 of debug_info_offset in .debug_aranges
> > http://dwarfstd.org/ShowIssue.php?issue=100816.1
> 
> I don't see how this one is relevant. This was really just an
> editorial change -- .debug_aranges physically could not point to a
> .debug_types section. In addition, with the type unit merge proposal,
> it becomes completely irrelevant (there will be no .debug_types
> section at all).

It is only relevant because it was a link between .debug_aranges and the
type units. If type units move to .debug_info then having them linked
like other units is what is needed to make aranges useful/complete. I
just mention it because looking at the individual proposals it might be
hard to see how an editorial change like that might impact other
proposals when you combine them.

> > One way might be to reverse the last proposal. Instead of removing the
> > aranges for type units (which did indeed not make much sense in the
> > split .debug_info/.debug_type approach), add an empty aranges header if
> > a type unit appears in .debug_info in the way of the second proposal for
> > address-less CUs.
> 
> I don't really like the idea of having aranges sections for type
> units. It would be nicer to keep type units separate, since there are
> *so* many more of them than there are compunits

Agreed. The same holds for partial units, which are often used in the
same way (though they aren't constrained to hold only type DIEs).

> , but for the
> accelerator table proposal, we needed a unified address space for the
> two, and this was the simplest way to accomplish that.

I might have missed that discussion.

> I think it's fine for a consumer to first assume that the
> .debug_aranges table is complete, but if an address lookup fails, then
> it can scan the .debug_info section, hopping from one CU/TU to the
> next, looking for CUs that aren't covered by .debug_aranges tables.

I think that is not very helpful. Unfortunately when introspecting or
debugging a program you often have "invalid" addresses, an uninitialized
pointer, a bad backtrace, a user might ask "does this register point to
a known function", etc. So the negative case will actually happen a lot,
meaning that you quickly would have to load and scan all .debug_info
anyway. And especially in a big program with lots of modules that can be
expensive.

> Having the debug_info length field in the aranges table would help,
> but even then, it's not clear to me how much it will help.

It only helps if producers follows best practices more often then not
and generate aranges headers for all units. Then you can at least use
the aranges headers to determine whether or not you really have to scan
the .debug_info to collect more ranges (and skip those you know are
already complete).

> With unified CUs and TUs, this scan will be costly with or without the
> length field -- for every CU, you'll probably have to skip over dozens
> or hundreds of TUs. It might help if we could guarantee that all CUs
> precede all TUs, but the only reasonable way to do that is to keep
> them in separate sections to begin with! Adding empty aranges tables
> for the TUs will bloat the .debug_aranges section significantly, and
> it would add a burden on the producers to make sure that the
> .debug_aranges contributions are in the same COMDAT group as the TU
> itself (GCC, for example, still doesn't put related sections in the
> same group).

Yes, all true. So you have to either generate (empty) arange headers for
all the TUs and PUs or move the no-ranges units somewhere else for the
consumer to be able to check the aranges table is complete.

Personally I think it makes sense to just mandate that producers make
sure the aranges headers are complete. Then you don't need to guess
whether there are some units not covered. Which means you don't need
producers to generate empty arange headers and you don't need the add
the debug info length to allow consumers to check whether all units are
covered. (Which is actually what we do in elfutils, we just
complain/file bugs against producers that don't generate aranges. GDB is
just a nicer consumer that tries to get things correct, but that does
mean a big memory/speed penalty at the moment unless both 100430.1 and
100430.2 are adopted.)

Cheers,

Mark