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