mstorsjo added a comment.

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.

> - I think we ought to have some kind of a utility function to hold the logic 
> for the `&~1` stuff. there is something like that in 
> Architecture::GetOpcodeLoadAddress. The Architecture class is mostly 
> independent of a target, so we may be able create one instance for each 
> module or symbol file, but that feels quite heavy. I might even go for 
> putting something like that into the ArchSpec class. The raison d'être of the 
> Architecture class was to evict some heavy code out of ArchSpec -- this was 
> ArchitectureArm::OverrideStopInfo. That one is definitely too heavy, so still 
> don't thing it belongs in ArchSpec, but the `&~1` thingy seems like it could 
> find a place there.)
> - is this behavior reproducible with lld ? If so, I think it'd make the test 
> more readable to run llvm-mc+lld as a part of the test

Yes it is. Ok, that's fine with me.

> - the address byte size would best be handled separately

On second thought, yes, this should be trivial to split out and make a similar 
test with inspecting line tables of an i386 binary.


Repository:
  rG LLVM Github Monorepo

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

Reply via email to