DavidSpickett wrote:
The problem is not to do with the debug symbols, or it being a "properly
remote" connection due to the proxy and that messing up search paths.
It's because evaluating an expression using JIT requires us to send a `vCont`
and something goes wrong there, it appears to be missing completely.
I know that if I stick `while (1) {}` at the end of the `main`, the test hangs
forever. Which tells me that the expression calling
mmap somehow ends up running to the end of main. Perhaps the PC gets reset? Or
we don't exec the expression at all.
Anyway, here is the log from a working non-proxied session, when I do `p
false_condition`:
```
lldb < 37> send packet: $QSaveRegisterState;thread:3486f4;#bd
lldb < 5> read packet: $3#33
lldb < 38> send packet: $P0=0000000000000000;thread:3486f4;#54
lldb < 6> read packet: $OK#9a
<...setup more argument registers...>
lldb < 21> send packet: $Z0,aaaaaaaaa600,4#15
lldb < 6> read packet: $OK#9a
<...placed a breakpoint for the return address which will be _start from the c
library...>
lldb < 22> send packet: $p20;thread:3486f4;#69
lldb < 20> read packet: $90f7fdf7ffff0000#c5
<...read a register for some reason...>
b-remote.async> < 22> send packet: $vCont;c:p3486f4.-1#4d
<...continue from the start of the expression wrapper function that we JIT'd...>
intern-state < 42> send packet: $QRestoreRegisterState:3;thread:3486f4;#7f
<...restore the original state...>
intern-state < 6> read packet: $OK#9a
```
This is the proxy's log for the same expression:
```
2024-10-11 16:01:36,939 INFO Sending packet _M1000,rwx
2024-10-11 16:01:36,939 INFO Received reply
2024-10-11 16:01:36,939 INFO Sending packet
QSaveRegisterState;thread:348766;
2024-10-11 16:01:36,940 INFO Received reply 1
2024-10-11 16:01:36,940 INFO Sending packet
P0=0000000000000000;thread:348766;
2024-10-11 16:01:36,940 INFO Received reply OK
2024-10-11 16:01:36,940 INFO Sending packet
P1=0010000000000000;thread:348766;
2024-10-11 16:01:36,940 INFO Received reply OK
2024-10-11 16:01:36,941 INFO Sending packet
P2=0700000000000000;thread:348766;
2024-10-11 16:01:36,941 INFO Received reply OK
2024-10-11 16:01:36,941 INFO Sending packet
P3=2200000000000000;thread:348766;
2024-10-11 16:01:36,941 INFO Received reply OK
2024-10-11 16:01:36,941 INFO Sending packet
P4=ffffffffffffffff;thread:348766;
2024-10-11 16:01:36,941 INFO Received reply OK
2024-10-11 16:01:36,941 INFO Sending packet
P5=0000000000000000;thread:348766;
2024-10-11 16:01:36,941 INFO Received reply OK
2024-10-11 16:01:36,942 INFO Sending packet
P1e=00a6aaaaaaaa0000;thread:348766;
2024-10-11 16:01:36,942 INFO Received reply OK
2024-10-11 16:01:36,942 INFO Sending packet
P1f=30edffffffff0000;thread:348766;
2024-10-11 16:01:36,942 INFO Received reply OK
2024-10-11 16:01:36,942 INFO Sending packet
P20=b01dbff7ffff0000;thread:348766;
2024-10-11 16:01:36,942 INFO Received reply OK
2024-10-11 16:01:36,942 INFO Sending packet Z0,aaaaaaaaa600,4
2024-10-11 16:01:36,943 INFO Received reply OK
2024-10-11 16:01:36,943 INFO Sending packet p0;thread:348766;
2024-10-11 16:01:36,943 INFO Received reply 0000000000000000
2024-10-11 16:01:36,943 INFO Sending packet p20;thread:348766;
2024-10-11 16:01:36,943 INFO Received reply b01dbff7ffff0000
2024-10-11 16:01:36,943 INFO Sending packet
QRestoreRegisterState:1;thread:348766;
2024-10-11 16:01:36,943 INFO Received reply OK
2024-10-11 16:01:36,944 INFO Sending packet p20;thread:348766;
2024-10-11 16:01:36,944 INFO Received reply 4ca7aaaaaaaa0000
2024-10-11 16:01:36,944 INFO Sending packet z0,aaaaaaaaa74c,4
2024-10-11 16:01:36,944 INFO Received reply OK
2024-10-11 16:01:36,944 INFO Sending packet vCont;s:p348766.348766
```
It's as if there is a vCont missing between the QSaveRegisterState and
QRestoreRegisterState.
Is it possible that because this trigger breakpoint is hit when running in
reverse, we're also trying to execute the expression "in reverse"? Getting very
confused, and deciding that not doing anything is the best solution.
Feels like the proxy's handling of vCont isn't at fault so much us running in
reverse but then needing to forward execute to evaluate the expression.
I'm testing this on an AArch64 machine but I think you might be able to trigger
this on X86 as well by making the breakpoint condition a function call instead
of a variable.
https://github.com/llvm/llvm-project/pull/99736
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
