dblaikie added a comment. In D70840#1765876 <https://reviews.llvm.org/D70840#1765876>, @mstorsjo wrote:
> In D70840#1765219 <https://reviews.llvm.org/D70840#1765219>, @labath wrote: > > > debug_aranges is a sort of a lookup table for speeding up address->compile > > unit searches. llvm does not generate it by default since, and I think the > > reason is that you can usually get the same kind of data from the > > DW_AT_ranges attribute of the compile unit. > > > Ok, thanks for the explanation! > > On the topic of debug_aranges (but unrelated to this thread), I've been > notified about a project, drmingw, a postmortem debugger for the mingw > environment (I think), which stumbles on code built by llvm exactly due to > the lack of debug_aranges: > https://github.com/jrfonseca/drmingw/issues/42#issuecomment-526850588 They > speculate that it almost even would be mandated by the dwarf spec. Yeah, I've had some conversations with folks on a couple of different things that have been curious about Clang/LLVM's lack of debug_aranges - my general take on it (as one of the people involved in turning off debug_aranges by default in LLVM's output - it can still be enabled by -gdwarf-aranges) is that they add a significant amount of object size for little benefit compared to the ranges on CU DIEs themselves. Clients who read input without aranges for a given CU should look in the CU DIE to see if there are ranges there - it should add very little overhead to consumers & save some significant debug info size (especially for split-dwarf in object sizes (where the relocations still exist & take up a fair bit of space - especially with compression enabled, where relocations are not compressed)). CHANGES SINCE LAST ACTION https://reviews.llvm.org/D70840/new/ https://reviews.llvm.org/D70840 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
