lldb - Registers are not restored if PrepareTrivialCall fails

[DavidSpickett]

In this example I have bodged the function to return false after writing the argument registers all to 99:

(lldb) run
Process 3666152 launched: '/tmp/test.o' (aarch64)
Process 3666152 stopped
* thread #1, name = 'test.o', stop reason = breakpoint 1.1
    frame #0: 0x0000aaaaaaaaa72c test.o`main at test.c:4:10
   1    int bar(int a) { return a*2; }
   2
   3    int main() {
-> 4      return 0;
   5    }
(lldb) register read --all
General Purpose Registers:
        x0 = 0x0000000000000001
        x1 = 0x0000fffffffff3a8
        x2 = 0x0000fffffffff3b8
        x3 = 0x0000aaaaaaaaa72c  test.o`main at test.c:4:10
        x4 = 0x0000000000000000
        x5 = 0x209f561e2fa866d7
        x6 = 0x0000fffff7facc90  libc.so.6`initial
        x7 = 0x0000004554415649

(lldb) p bar(1)

error: Can't evaluate the expression without a running target due to: Interpreter doesn't handle one of the expression's opcodes

Here we should have restored the original values, but:

(lldb) register read --all
General Purpose Registers:
        x0 = 0x0000000000000063
        x1 = 0x0000000000000063
        x2 = 0x0000000000000063
        x3 = 0x0000000000000063
        x4 = 0x0000000000000063
        x5 = 0x0000000000000063

We did not.

This is 99.9% of the time not a problem as preparing a trivial call does trivial things, but in adding Arm GCS support I had to handle the failure path and found this.

For that, I'm going to handle the one case I need, but I will come back and try to make LLDB restore everything properly.

[llvmbot]

@llvm/issue-subscribers-lldb

Author: David Spickett (DavidSpickett)

In this example I have bodged the function to return false after writing the argument registers: ``` (lldb) run Process 3666152 launched: '/tmp/test.o' (aarch64) Process 3666152 stopped * thread #1, name = 'test.o', stop reason = breakpoint 1.1 frame #0: 0x0000aaaaaaaaa72c test.o`main at test.c:4:10 1 int bar(int a) { return a*2; } 2 3 int main() { -> 4 return 0; 5 } (lldb) register read --all General Purpose Registers: x0 = 0x0000000000000001 x1 = 0x0000fffffffff3a8 x2 = 0x0000fffffffff3b8 x3 = 0x0000aaaaaaaaa72c test.o`main at test.c:4:10 x4 = 0x0000000000000000 x5 = 0x209f561e2fa866d7 x6 = 0x0000fffff7facc90 libc.so.6`initial x7 = 0x0000004554415649

(lldb) p bar(1)

error: Can't evaluate the expression without a running target due to: Interpreter doesn't handle one of the expression's opcodes

Here we should have restored the original values, but:

(lldb) register read --all
General Purpose Registers:
x0 = 0x0000000000000063
x1 = 0x0000000000000063
x2 = 0x0000000000000063
x3 = 0x0000000000000063
x4 = 0x0000000000000063
x5 = 0x0000000000000063

We did not.

This is 99.9% of the time not a problem as preparing a trivial call does trivial things, but in adding Arm GCS support I had to handle the failure path and found this.

For that, I'm going to handle the one case I need, but I will come back an try to make LLDB restore everything properly.
</details>

[jimingham]

Why did we think we didn't have a running target? Your error is:

Can't evaluate the expression without a running target due to...

If we think we don't have a running target, or course we aren't going to try to restore register state, but you clearly DID have a running target...

[DavidSpickett]

error: Can't evaluate the expression without a running target due to: Interpreter doesn't handle one of the expression's opcodes

I suspect this is an error that would normally only show up when we do have a working target, but not restoring the registers got it into a state where it was "running" but definitely not working.

The restore path I added will avoid that scenario.