labath added a comment. In D68655#4048009 <https://reviews.llvm.org/D68655#4048009>, @jasonmolenda wrote:
> In D68655#4047126 <https://reviews.llvm.org/D68655#4047126>, @labath wrote: > >> In D68655#4045895 <https://reviews.llvm.org/D68655#4045895>, @jasonmolenda >> wrote: >> >>> Both have to be written by the dwarf linker to be correct, but only the >>> former is written ONLY by the dwarf linker. >> >> I don't think that's right: >> >> $ clang -c -x c - -o - -gdwarf-aranges -g <<<"void f(){}" | llvm-readelf - >> --sections | grep aranges >> [ 6] .debug_aranges PROGBITS 0000000000000000 0000a0 000030 00 >> 0 0 1 >> [ 7] .rela.debug_aranges RELA 0000000000000000 000380 000030 18 >> I 20 6 8 > > Ah thanks Pavel, clang on Darwin doesn't emit this in .o files. It does. It just doesn't do it by default -- same as on linux (but not on PS4 I believe). You have to use the -gdwarf-aranges flag explicitly (which, quite possibly, noone does), > So in this case, the .o file has a DW_TAG_compile_unit with a DW_AT_ranges > and a .debug_aranges, both generated pre-link-time by the compiler. Yes. > And Greg is saying that the DW_AT_ranges list in the final executable will be > better than the .debug_aranges? I don't know how strongly he asserts this - > today if a .debug_aranges has an entry, we don't look at > DW_TAG_compile_unit's DW_AT_ranges, or create the ranges ourself via the line > table; the debug_aranges is trusted above the other methods if it includes CU. That I don't know. Personally, I would expect the two to be equivalent, except that the debug_aranges could theoretically be faster to parse (and takes up more space). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68655/new/ https://reviews.llvm.org/D68655 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
