jasonmolenda added a comment. In D141330#4043397 <https://reviews.llvm.org/D141330#4043397>, @labath wrote:
> In D141330#4037932 <https://reviews.llvm.org/D141330#4037932>, @JDevlieghere > wrote: > >> In D141330#4037925 <https://reviews.llvm.org/D141330#4037925>, @aprantl >> wrote: >> >>> Should this be true for a fully linked ELF executable, too? >> >> Sounds reasonable, but adding @labath and @DavidSpickett to confirm. This is >> trivial to extend later. > > It sounds like this is depends on whoever produced the file, not on the file > format. It's not even the producer (compiler/assembler) - it's the linker (or whatever links the dwarf) that needs to generate the table, and we can't detect that from the debug info. We need (1) a guarantee that every compile unit which generated code in the debug_info has an entry in debug_aranges, (2) a guarantee that all of the address ranges that come from the CU are described, and (3) a guarantee that the ranges in debug_aranges are unique, that no address will map to multiple compile units. The description in the dwarf v5 doc includes, By scanning the table, a debugger can quickly decide which compilation unit to look in to find the debugging information for an object that has a given address. If the range of addresses covered by the text and/or data of a compilation unit is not contiguous, then there may be multiple address range descriptors for that compilation unit. (I dislike it when the standard says "there MAY be multiple address range descriptors" -- does this mean if I have a noncontiguous CUs A and B interleaved in the final binary, the debug_aranges can overlap?) There's no guarantee for (1) if a debug_aranges table is present, but maybe we can simply assume that any producer producing debug_aranges has done so comprehensively. I couldn't imagine why it wouldn't be that way. The point of this patch, of course, is to skip the verification of (1) - that every CU that generated functions in the final binary has a debug_aranges entry. It turns out we have compile units in debug_info that don't emit any functions, and lldb would see those as missing from debug_aranges and iterate over the DIEs looking for subprograms. Maybe lldb should simply trust that if debug_aranges exists, all of 1-3 are true, and revisit it when/if we get bug reports of some random toolchain in the world violating that assumption. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D141330/new/ https://reviews.llvm.org/D141330 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
