[Lldb-commits] [PATCH] D70840: [LLDB] [DWARF] Strip out the thumb bit from addresses on ARM

[David Blaikie via Phabricator via lldb-commits]

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