mstorsjo added a comment. In D70840#1871932 <https://reviews.llvm.org/D70840#1871932>, @labath wrote:
> In D70840#1871862 <https://reviews.llvm.org/D70840#1871862>, @mstorsjo wrote: > > > > 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? > > > Lldb uses this when unwinding specifically to deal with the "call as a last > instruction" problem, and I'm pretty sure it's not the only tool doing that. > This is even described in the DWARF spec (non-normative text): > > > In most cases the return address is in the same context as the calling > > address, but that > > need not be the case, especially if the producer knows in some way the > > call never will > > return. The context of the ’return address’ might be on a different line, > > in a different > > lexical block, or past the end of the calling subroutine. If a consumer > > were to assume that > > it was in the same context as the calling address, the virtual unwind > > might fail. > > > > For architectures with constant-length instructions where the return address > > immediately follows the call instruction, a simple solution is to subtract > > the length of an > > instruction from the return address to obtain the calling instruction. For > > architectures > > with variable-length instructions (for example, x86), this is not > > possible. However, > > subtracting 1 from the return address, although not guaranteed to provide > > the exact > > calling address, generally will produce an address within the same context > > as the calling > > address, and that usually is sufficient. > > Using `GetOpcodeLoadAddress(pc) - 1` would work, but this implies that the > caller should be passing in "load" addresses, which is in conflict with the > premise I have made at the beginning of the paragraph that one should be > passing in "code" addresses here. (My attempt at proof by contradiction.) Ah, I see - so this also is another argument for making things work with "load" addresses - good then. 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
