labath added a comment. 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. 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. Either way, there's some fixup that needs to happen somewhere... 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
