Hi Frank, On Thu, Feb 22, 2024 at 10:35 AM Frank Ch. Eigler <f...@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
