Failure to build librseq on ppc

Christophe Leroy christophe.leroy at csgroup.eu
Thu Jul 9 00:21:54 AEST 2020



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.

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