Re: [PATCH v3 4/5] tests/tcg/s390x: Fix EXRL tests

[David Hildenbrand]

On 12.01.21 09:16, Thomas Huth wrote:
> On 12/01/2021 08.47, David Hildenbrand wrote:
>>
>>> Am 12.01.2021 um 08:41 schrieb Thomas Huth <thuth@redhat.com>:
>>>
>>> On 11/01/2021 17.38, David Hildenbrand wrote:
>>>> The current EXRL tests crash on real machines: we must not use r0 as a base
>>>> register for trt/trtr, otherwise the content gets ignored. Also, we must
>>>> not use r0 for exrl, otherwise it gets ignored.
>>>> Let's use the "a" constraint so we get a general purpose register != r0.
>>>> For op2, we can simply specify a memory operand directly via "Q" (Memory
>>>> reference without index register and with short displacement).
>>>> Fixes: ad8c851d2e77 ("target/s390x: add EX support for TRT and TRTR")
>>>> Signed-off-by: David Hildenbrand <david@redhat.com>
>>>> ---
>>>>   tests/tcg/s390x/exrl-trt.c  | 8 ++++----
>>>>   tests/tcg/s390x/exrl-trtr.c | 8 ++++----
>>>>   2 files changed, 8 insertions(+), 8 deletions(-)
>>>> diff --git a/tests/tcg/s390x/exrl-trt.c b/tests/tcg/s390x/exrl-trt.c
>>>> index 3c5323aecb..16711a3181 100644
>>>> --- a/tests/tcg/s390x/exrl-trt.c
>>>> +++ b/tests/tcg/s390x/exrl-trt.c
>>>> @@ -19,7 +19,7 @@ int main(void)
>>>>       }
>>>>       asm volatile(
>>>>           "    j 2f\n"
>>>> -        "1:  trt 0(1,%[op1]),0(%[op2])\n"
>>>> +        "1:  trt 0(1,%[op1]),%[op2]\n"
>>>>           "2:  exrl %[op1_len],1b\n"
>>>>           "    lgr %[r1],%%r1\n"
>>>>           "    lgr %[r2],%%r2\n"
>>>> @@ -27,9 +27,9 @@ int main(void)
>>>>           : [r1] "+r" (r1),
>>>>             [r2] "+r" (r2),
>>>>             [cc] "=r" (cc)
>>>> -        : [op1] "r" (&op1),
>>>> -          [op1_len] "r" (5),
>>>> -          [op2] "r" (&op2)
>>>> +        : [op1] "a" (&op1),
>>>> +          [op1_len] "a" (5),
>>>
>>> I think op1_len could still stay with "r" instead of "a" ... OTOH "a" also 
>>> does not hurt here, so:
>>>
>>
>> No, otherwise exrl ignores the register content  if it ends up being r0.
> 
> Ah, well, sorry, I've got fooled by the description of "EXECUTE RELATIVE 
> LONG" in the Principles of Operation since it is talking about "R1" and not 
> "B" there ... but you're right, the detailed description there then talks 
> about "When the R1 field is not zero ...", so we need the "a" instead of the 
> "r" for op1_len here indeed.

I actually stumbled over that while fixing the test. Converting op1 and
op2 suddenly made the test fail with "bad cc" instead of segfault. The
compiler decided to use r0 for op1_len when not being able to use it for
op1 and op2 ... :)


-- 
Thanks,

David / dhildenb