BTW, I think the better way to handle this in lldb is not to move the PC past the trap when you stop, but that when CONTINUING past a trap that we don't recognize, we always make sure we start past the trap. That way it won't look weird when people compare crash logs coming from hitting a trap with backtraces in lldb, but we would still get the desired behavior.
Jim > On Mar 4, 2020, at 11:29 PM, Pavel Labath <pa...@labath.sk> wrote: > > On 04/03/2020 21:45, Jim Ingham via llvm-dev wrote: >> As you have seen, different machine architectures do different things after >> hitting a trap. On x86_64, the trap instruction is executed, and then you >> stop, so the PC is left after the stop. On arm64, when execution halts the >> pc is still pointing at the trap instruction. >> >> I don't think lldb should be in the business of telling systems how they >> should report stops, especially since that is certainly something we can >> handle in lldb. >> >> For traps that lldb recognizes as ones it is using for breakpoints, it >> already has to handle this difference for you. But for traps we know >> nothing about we don't do anything special. >> >> I think it would be entirely reasonable that whenever lldb encounters a trap >> instruction that isn't one of ours it should always move the PC after the >> trap before returning control to the user. I can't see why you would want >> to keep hitting the trap over and over. I've received several bugs (on the >> Apple bug reporter side) for this feature. This might be something we teach >> lldb-server & debugserver to do, rather than lldb but that's an >> implementation detail... >> >> For now, on architectures where the trap doesn't execute, you just need to >> move the pc past the trap by hand (with the "thread jump" command) before >> continuing. That has always been safe on arm64 so far as I can tell. >> >> Jim > > Yes, this is something that has bugged me too. > > While I think it would be nice if the OSes hid these architecture quirks > (hell, I think it would be nice if the CPU manufacturers made this > consistent so that the OS doesn't need to hide it), I think that > changing that at this point is very unlikely, and so working around it > in lldb is probably the best we can do. > > I am not sure what is the official position on continuing from a debug > trap, but I think that without that ability, the concept would be pretty > useless. A quick example <https://godbolt.org/z/-8voBz> shows that clang > produces the "expected" output even at -O3. In fact, on aarch64, > __builtin_debugtrap() and __builtin_trap() produce the same instruction, > and the only difference between them is that the latter also triggers > DCE of everything coming after it. > > pl _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
