dblaikie added a subscriber: rnk. dblaikie added a comment. In D70840#1765219 <https://reviews.llvm.org/D70840#1765219>, @labath wrote:
> 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.) Yeah, I don't know much about the ARM tagged pointer stuff, but if the tags don't appear in the return addresses in a stack trace & thus the addresses you'd pass to llvm-symbolizer then I think it'd make sense to implement it somewhere in LLVM's libDebugInfoDWARF (& yeah, don't know about PDB either, perhaps @rnk does). If there is no common code between debug_aranges and other address parsing -perhaps there should be? a filter of some kind that could be used for all addresses being read? 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
