On 07/16/2017 05:18 AM, Aurelien Jarno wrote:
That said for further improvements did you consider decoding the gUSA
section in a helper. It might avoid having to emulate the atomic
sequence with 3 TBs in the worst case (the original one, the one to
decode the sequence and the one holding the exclusive lock). The helper
should directly have access to the r0 value, can decode the atomic
sequence and translate it into a call to the corresponding atomic
helpers. In the best case that means the sequence can be done in the
same TB. In the worst case, where the gUSA sequence is not recognized
it means two TB.
I did not consider decoding the sequence in a helper.
I do want to cache the result in a TB, so that when we execute the atomic
sequence for a second time we do not have to re-interpret it. And I don't see
how to do that with a helper.
I *could* remember a mova into R0 earlier within the same block that performs
the mov #imm,r15. It's not guaranteed to be in the same TB, but looking
through dumps from debian unstable it's highly likely.
That could end up with the atomic sequence in the same TB that set SP, or with
the EXCP_ATOMIC exception in the same TB.
If it's ok with you, I'd prefer to handle that as a follow up. We would still
have to have the current setup as a backup just in case the mova isn't visible.
r~