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

[Martin Storsjö via Phabricator via lldb-commits]

mstorsjo marked an inline comment as done.
mstorsjo added a comment.

In D70840#1765219 <https://reviews.llvm.org/D70840#1765219>, @labath wrote:

> 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.


Ok, thanks for the explanation!

On the topic of debug_aranges (but unrelated to this thread), I've been notified about a project, drmingw, a postmortem debugger for the mingw environment (I think), which stumbles on code built by llvm exactly due to the lack of debug_aranges: https://github.com/jrfonseca/drmingw/issues/42#issuecomment-526850588 They speculate that it almost even would be mandated by the dwarf spec.

> 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?)

Not sure actually, I'd have to check. (FWIW, llvm doesn't support generating codeview debug info for PDB for ARM, only x86 and aarch64, but I could check with MSVC tools.)



================
Comment at: lldb/include/lldb/Symbol/LineTable.h:333
+
+  bool m_clear_address_zeroth_bit = false;
 };
----------------
clayborg wrote:
> Might be nice to let the line table parse itself first, and then in a post production step clean up all the addresses? Maybe
> 
> ```
> void LineTable::Finalize(Architecture *arch);
> ```
> 
> Then we let the architecture plug-in handle any stripping using:
> 
> ```
> lldb::addr_t Architecture::GetOpcodeLoadAddress(lldb::addr_t addr, AddressClass addr_class) const;
> ```
> 
> The ArchitectureArm plugin does this:
> 
> ```
> addr_t ArchitectureArm::GetOpcodeLoadAddress(addr_t opcode_addr,
>                                              AddressClass addr_class) const {
>   switch (addr_class) {
>   case AddressClass::eData:
>   case AddressClass::eDebug:
>     return LLDB_INVALID_ADDRESS;
>   default: break;
>   }
>   return opcode_addr & ~(1ull);
> }
> ```
> 
> 
Thanks for all the pointers and the explanations! I'll try to have a look into all of this in a few days.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70840/new/

https://reviews.llvm.org/D70840