[Dwarf-Discuss] Interaction between aranges and unit proposals

[Tom Tromey]

Tom> However, the completeness property is probably more important for
Tom> by-name indices, where you don't want a single typo to destroy whatever
Tom> performance gain you get from an index.

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

I think, first, use some other method to determine whether the address
is plausible -- say looking at the load map -- and then, second, just
accept the performance hit in this case; noting that only CUs which are
not mentioned in .debug_aranges need be searched.

I am not especially pleased about an unreliable index, but in the
specific case of addresses, I imagine one is relatively unlikely to see
an address which looks plausible according to the runtime but which is
actually invalid after an exhaustive search.

This is distinct from the by-name situation, where, at least in gdb,
it's common for users to mistype a function name.

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

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

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

I think in the typical edit-compile-debug cycle, nobody creates the
.gdb_index either :)

I do take your point.  But I think it's also worth considering how
unusual the .debug_aranges failure mode really is.  Basically you need
to have hand-written assembly where you put in the effort to write
.debug_info but failed to account for .debug_aranges.  And perhaps even
then it would be possible to hack gas to DTRT.

Tom