labath added reviewers: JDevlieghere, aprantl. labath added a subscriber: dblaikie. labath added a comment.
Throwing some additional dwarf people in here... In D70840#1763750 <https://reviews.llvm.org/D70840#1763750>, @mstorsjo wrote: > In D70840#1763705 <https://reviews.llvm.org/D70840#1763705>, @mstorsjo wrote: > > > In D70840#1763639 <https://reviews.llvm.org/D70840#1763639>, @labath wrote: > > > > > Yeah, this is going to be tricky... I don't really know what's the right > > > way to do this, but here are the thoughts I have on this so far: > > > > > > - The new DWARFDebugInfoEntry member is going to substantially increase > > > our memory footprint -- that's a non-starter > > > > > > Ok, I feared that class was one where the size is critical yeah... > > > > > - I don't like the inconsistency where all addresses are demangled in the > > > DWARF code, except the line tables, which are in the "generic" code > > > > Yup. The reason for doing it like this was as I tried to find the most > > narrow interface where I could catch all of them. > > > Is there any corresponding place in generic code where one could do the same > operation on the addresses that comes from pc_lo/pc_hi ranges from > .debug_info and .debug_aranges (not familiar with this section and when it's > generated etc), if that would end up touching fewer places? The existing > predecent in DWARFCallFrameInfo::GetFDEIndex is dwarf specific, but in > generic code outside of the dwarf symbolfile plugin. 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. I don't think you would be able to handle that in generic code, as debug_aranges does not make it's way into generic code. Overall, I think this needs to be handled in DWARF code. That may even make sense, since PDB may not suffer from the same problem (does it?) TBH, the `m_addr_mask` member issue is not that hard to resolve -- all DWARFDebugInfoEntry functions get a DWARFUnit argument (otherwise they wouldn't be able to do anything). Theoretically, we could store the mask there. However, the question on my mind is what does that say about the llvm<->lldb dwarf parser convergence (one of our long term goals is to delete the lldb dwarf parser altogether, leaving just the high level lldb-specific stuff). Adding mask handling code low into the dwarf parser would go against that goal, as there is no equivalent llvm functionality. One possible solution would be to try to add equivalent llvm functionality -- it sounds like something like this is needed there too, as all llvm tools (I don't know if there's anything besides llvm-symbolizer) will probably not work without it. (If they do, it would be interesting to figure out how they manage that.) Another possibility might be to implement this in the higher levels of the dwarf code (the parts that are likely to stay in lldb forever)... 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
