Failure to build librseq on ppc

Christophe Leroy christophe.leroy at csgroup.eu
Thu Jul 9 02:11:30 AEST 2020



Le 08/07/2020 à 16:32, Mathieu Desnoyers a écrit :
> ----- On Jul 8, 2020, at 10:21 AM, Christophe Leroy christophe.leroy at csgroup.eu wrote:
> 
>> Le 08/07/2020 à 16:00, Mathieu Desnoyers a écrit :
>>> ----- On Jul 8, 2020, at 8:33 AM, Mathieu Desnoyers
>>> mathieu.desnoyers at efficios.com wrote:
>>>
>>>> ----- On Jul 7, 2020, at 8:59 PM, Segher Boessenkool segher at kernel.crashing.org
>>>> wrote:
>>> [...]
>>>>>
>>>>> So perhaps you have code like
>>>>>
>>>>>    int *p;
>>>>>    int x;
>>>>>    ...
>>>>>    asm ("lwz %0,%1" : "=r"(x) : "m"(*p));
>>>>
>>>> We indeed have explicit "lwz" and "stw" instructions in there.
>>>>
>>>>>
>>>>> where that last line should actually read
>>>>>
>>>>>    asm ("lwz%X1 %0,%1" : "=r"(x) : "m"(*p));
>>>>
>>>> Indeed, turning those into "lwzx" and "stwx" seems to fix the issue.
>>>>
>>>> There has been some level of extra CPP macro coating around those instructions
>>>> to
>>>> support both ppc32 and ppc64 with the same assembly. So adding %X[arg] is not
>>>> trivial.
>>>> Let me see what can be done here.
>>>
>>> I did the following changes which appear to generate valid asm.
>>> See attached corresponding .S output.
>>>
>>> I grepped for uses of "m" asm operand in Linux powerpc code and noticed it's
>>> pretty much
>>> always used with e.g. "lwz%U1%X1". I could find one blog post discussing that %U
>>> is about
>>> update flag, and nothing about %X. Are those documented ?
>>
>> As far as I can see, %U is mentioned in
>> https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html in the
>> powerpc subpart, at the "m" constraint.
> 
> Yep, I did notice it, but mistakenly thought it was only needed for "m<>" operand,
> not "m".

You are right, AFAIU on recent versions of GCC, %U has no effect without m<>

Christophe

> 
> Thanks,
> 
> Mathieu
> 
>>
>> For the %X I don't know.
>>
>> Christophe
>>
>>>
>>> Although it appears to generate valid asm, I have the feeling I'm relying on
>>> undocumented
>>> features here. :-/
> 


More information about the Linuxppc-dev mailing list