Re: [PATCH v2] dwarf_getaranges: Build aranges list from CUs instead of .debug_aranges

[Aaron Merey <amerey@redhat.com>]

Hi Frank,

On Thu, Feb 22, 2024 at 10:35 AM Frank Ch. Eigler <fche@redhat.com> wrote:
>
> > > We could then also introduce a new public function, dwarf_getdieranges
> > > (?) that does the new thing. But it doesn't have to be public on the
> > > first try as long as dwarf_addrdie and dwfl_module_addrdie work. (We
> > > might want to change the interface of dwarf_getdieranges so it can be
> > > "lazy" for example.)
> >
> > Ok this approach seems like the most flexible.  Users can have both
> > .debug_aranges and CU-based aranges plus we don't have to change the
> > semantics of dwarf_getaranges.  [...]
>
> Another option is to generate the .debug_aranges automatically, but
> only if it is absent from the input dwarf file.  (An eu-readelf user
> can tell if it was synthetic or not, if it matters.)

I'd like to be able to do this but .debug_aranges might be incomplete
even if the section is present in the input file.  This would require
us to parse CUs anyways in order to verify the section's completeness.

I'll defer to David Blaikie [1] again: "consumers shouldn't rely on the
presence of .debug_aranges, or them being complete (DWARF doesn't
require/guarantee this - and Clang doesn't emit aranges by default, for
instance). Each contribution to .debug_aranges says which CU it covers
and any CUs not covered should be parsed/assumed to contain things
covering other addresses."

Aaron

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=22288#c5