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