Failure to build librseq on ppc

[Mathieu Desnoyers]

----- 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".

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. :-/

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com