drreg-test fails with non-default stolen register

[egrimley]

This only seems to be a problem on AArch64, not 32-bit ARM.

bin64/drrun -steal_reg 28 -c suite/tests/bin/libclient.drreg-test.dll.so -- suite/tests/bin/client.drreg-test

works, but

bin64/drrun -steal_reg 27 -c suite/tests/bin/libclient.drreg-test.dll.so -- suite/tests/bin/client.drreg-test

fails (at translate.c:770).

Note that https://codereview.appspot.com/316900043/ removes one hardwired reference to X28, but the bug is not fixed by that commit and there don't seem to be any other similar references, so it might be something more subtle.

[egrimley]

Interestingly, although my recursive grepping didn't reveal any hardwired references to X28, there do seem to be a couple of hardwired references to DR_REG_R10, in translate.c and instr_shared.c. That might be relevant, though there could also be some kind of AArch64-specific fragment prefix or veneer or whatever that is not correctly handled by translation.

[egrimley]

It works with most values for steal_reg, but it fails when the stolen register is X19, X25 or X27. Why those values? Because those are the values to be found in the register fields of 0xf36d19, which is the "udf" instruction used in drreg-test.c!

So I could make the problem go away by choosing a different unallocated encoding, or by getting the decoder to recognise certain unallocated encodings, but I suspect there may be a bug in DynamoRIO with the handling of a fault on an instruction that really does access the stolen register...

[egrimley]

Yes, it looks as though the problem can be reproduced on AArch32 as follows:

Replace ".word 0xe7f000f0 /* udf */" with "swp r10, r10, [r0]", then run drreg-test on ARMv8 hardware, without kernel emulation of SWP, so that SWP causes a SIGILL. Then the test fails in the same way as it fails on AArch64. But you can make it pass by specifying "-steal_reg 9" or "-steal_reg 11".

So there seems to be a non-AArch64-specific bug in the handling of faults on instructions that access the stolen register, and this bug has nothing to do with the two references to DR_REG_R10 mentioned above (which might constitute a separate bug).