Failure to build librseq on ppc
Segher Boessenkool
segher at kernel.crashing.org
Fri Jul 10 06:46:09 AEST 2020
On Thu, Jul 09, 2020 at 01:56:19PM -0400, Mathieu Desnoyers wrote:
> > Just to make sure I understand your recommendation. So rather than
> > hard coding r17 as the temporary registers, we could explicitly
> > declare the temporary register as a C variable, pass it as an
> > input operand to the inline asm, and then refer to it by operand
> > name in the macros using it. This way the compiler would be free
> > to perform its own register allocation.
> >
> > If that is what you have in mind, then yes, I think it makes a
> > lot of sense.
>
> Except that asm goto have this limitation with gcc: those cannot
> have any output operand, only inputs, clobbers and target labels.
> We cannot modify a temporary register received as input operand. So I don't
> see how to get a temporary register allocated by the compiler considering
> this limitation.
Heh, yet another reason not to obfuscate your inline asm: it didn't
register this is asm goto.
A clobber is one way, yes (those *are* allowed in asm goto). Another
way is to not actually change that register: move the original value
back into there at the end of the asm! (That isn't always easy to do,
it depends on your code). So something like
long start = ...;
long tmp = start;
asm("stuff that modifies %0; ...; mr %0,%1" : : "r"(tmp), "r"(start));
is just fine: %0 isn't actually modified at all, as far as GCC is
concerned, and this isn't lying to it!
Segher
More information about the Linuxppc-dev
mailing list