On Wed, Mar 10, 2021 at 2:36 PM Cary Coutant <ccout...@gmail.com> wrote:
> On Wed, Mar 10, 2021 at 1:27 PM David Blaikie <dblai...@gmail.com> wrote: > > > > On Wed, Mar 10, 2021 at 1:16 PM Cary Coutant <ccout...@gmail.com> wrote: > >> > >> > But what about the DW_AT_ranges on the skeleton CU when using split > DWARF? > >> > > >> > Are you suggesting that both LLVM and GCC's emission is incorrect - > and that it's not possible to use rnglistx in the skeleton CU (instead you > must use sec_offset for DW_AT_ranges on the skeleton CU)? (& that there's > no way to refer to range lists in the .o (debug_rnglists) from the .dwo - > all ranges in the split full unit must be in debug_rnglists.dwo?) > >> > >> If you've moved range lists over to the dwo, having DW_AT_ranges in > >> the skeleton CU would be pointless — the consumer would still have to > >> go find the dwo to get the ranges. > >> > >> For the case you suggested where it would be useful to keep the range > >> list for the CU in the .o file, I think .debug_aranges is what you're > >> looking for. > > > > > > aranges has been off by default in LLVM for a while - it adds a lot of > overhead (doesn't have all the nice rnglist encodings for instance - nor > can it use debug_addr, and if it did it'd still be duplicate with the CU > ranges wherever they were). > > > > DWARFv5 says: > > > > "A skeleton compilation unit may have additional attributes, which are > the same as for conventional compilation unit entries except as noted, from > among the following: > > 2. Either a DW_AT_low_pc and DW_AT_high_pc pair of attributes or a > DW_AT_ranges attribute." > > > > and > > > > "The following attributes are not part of a split full compilation unit > entry but instead are inherited (if present) from the corresponding > skeleton compilation unit: DW_AT_low_pc, DW_AT_high_pc, DW_AT_ranges, ..." > > > > Even before the rnglist move, this still disallowed using > DW_AT_low/high_pc with addrx encodings from the split full unit, instead > requiring them to be in the skeleton unit. I think this is the right call > (& guess it was motivated by this use case) to make for cheap unit lookup. > > Hmm. I'm thinking that wording is from before the rnglist move, and > did not get updated properly. Or maybe it was intentional, but not > thought all the way through. Forcing DW_AT_ranges to be in the > skeleton CU when the actual range lists are in the dwo is silly. > DW_AT_low_pc/_high_pc in the skeleton makes sense, though. > Why one but not the other? Pre-range move, we could've still had smaller skeleton CUs (& thus smaller objects/executables) if low/high/ranges were all in the split full unit - using addrx and the v4 fission prototype style ranges_base-relative offsets. Yeah, the wiki write up for Fission ( https://gcc.gnu.org/wiki/DebugFission ) doesn't mention the motivation for DW_AT_low_pc, DW_AT_high_pc, DW_AT_ranges, and DW_AT_stmt_list to be in the skeleton unit. stmt_list makes sense because it needs to be relocated to refer to the .debug_line contribution wherever it's linked in. (oh, I guess there's another use case for low/high/ranges in the .o - it means you can symbolize (without inline stack frames) without dwo files present - and with two level line tables you could do full symbolization without dwo files) In any case I disagree that forcing ranges to be on the skeleton CU is silly - it's important to use cases I care about/support (& I think is pretty generally a good idea, but wouldn't strenuously object if someone really wanted the freedom to put it in the split full unit if they really want to/have a use case). But you've got me thinking.... Perhaps we should have *both* > .debug_rnglists *and* .debug_rnglists.dwo. The former could contain > only the range list needed for the DW_AT_ranges attribute in the > skeleton CU, while the latter would contain the range lists for any > DW_AT_ranges attributes in the dwo sections. > That's what LLVM emits today, so I'm certainly in favor of it. (& that got me thinking to those relationship diagram appendices - and indeed "Figure B.2: Split DWARF section relationships" is another inconsistency, leaning towards your description, since it does not include a .debug_rnglists non-dwo section in the diagram) Which comes back to the "what does rnglists_base on a skeleton .o file mean, if anything" - should the ranges on the skeleton CU always use sec_offset (never rnglistx), or can you use rnglists_base on the skeleton CU , rnglistx in both skeleton and split full - and the rnglistx in the split full unit always refer to rnglists.dwo no matter what's going on in the skeleton - and the rnglistx in the skeleton uses the rnglists_base? That's what LLVM does today and seems consistent/general. I'd say the fix to the wording would be to say that DW_AT_rnglists_base is not inherited by the split full CU from the skeleton CU, and split full CUs effectively always have an implicit rnglists_base of <sizeof rnglists header>. (plus fixing the block diagram) > If you (LLVM) are already choosing not to use .debug_aranges for quick > address lookup, does that suggest that per-CU ranges are sufficient? > Yes > Can we get rid of .debug_aranges? > I think that would be good as far as my use cases & other uses I can think of are concerned - but I think I remember there being some reasonable disagreement there last time it was discussed maybe in the LLVM community (arangas is off-by-default, but LLVM can produce them when asked and I think some users do turn them on) - Dave
_______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org