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

[Martin Storsjö via Phabricator via lldb-commits]

mstorsjo added a comment.

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

> I did not send out any emails for this, but I did talk about this with @dblaikie when I was in the US last week. My take from that is that we should start by "fixing" llvm-symbolizer so that it works reasonably in these cases. I'll use this <https://godbolt.org/z/EEu5iZ> godbolt link to illustrate what I mean.
>
> If we take a look at the `deref` function in that link, and try to pass the address of the first instruction `ldr     r0, [r0]` to llvm-symbolizer, then we will get something reasonable in the non-windows case, but we will get nothing in the windows case, because the debug info would claim that the function starts halfway into that opcode. Fixing the tool so that it returns the same thing everywhere sounds reasonable, and since it does both line table and debug_info lookups, this will already answer the main questions we have about where this logic should be implemented. Then we can just copy that in lldb.


Thanks for keeping track of this! I'll look into fixing this at some suitable level for llvm-symbolizer for further discussion.

> Now someone might argue that the looking up the address of the `ldr` opcode is wrong, because that is not the actual pc value, and that we should lookup the address of `ldr+1`. In that case we can point them to the next function (`call_noreturn`), which ends with a call to a noreturn function. Now if we get a crash in `does_not_return()`, the address we will get from the backtrace will be one byte after the last opcode of `call_noreturn` (`bl      does_not_return()`). This means that in the **non-windows** case, it will not resolve correctly to the `call_noreturn` even if we apply the usual trick of subtracting 1 from the address to bring it into the range of the calling function.

Hmm... I presume this issue is present now already (and doesn't really change due to normalizing the line tables and ranges on windows, to the same as linux). Not familiar with "the usual trick of subtracting 1 from the address to bring it into the range of the calling function", but wouldn't something like `GetOpcodeLoadAddress(pc) - 1` always bring you into the range of the calling function, given a return address?


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

https://reviews.llvm.org/D70840