llvm dev - Mar 2020 - [lldb-dev] Continuing from dbgtrap on different targets

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

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 <pavel at 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

That shouldn't be too hard to do.  We already have machinery to inject a
"step over breakpoint trap" ThreadPlan when we continue, so we could
use the same detection point to just move the PC before continuing in the case
of an unrecognized trap.

Jim

> On Mar 5, 2020, at 10:10 AM, Jim Ingham via lldb-dev <lldb-dev at
lists.llvm.org> wrote:
> 
> 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 <pavel at 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 at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev