After reading the various ABI guides it seems like the original workaround to
appease -fno-omit-frame-pointer may have unintended side effects. If GCC is no
longer aware of r31 being tampered with it cannot be guaranteed to preserve r31
in the GP Regs section of the stack via the generated prologue and epilogue.
Would it not be better to for now state that -fno-omit-frame-pointer is
violating the ABI used in practice and should be avoided on the powerpc
platform? In my search for understanding I found people coming to a similar
conslusion in their use of gcc to compile the Linux kernel for the powerpc
architecture.
Warm Regards,
Adam
________________________________________
From: port-powerpc-owner%NetBSD.org@localhost
[port-powerpc-owner%NetBSD.org@localhost] on behalf of Dennis Ferguson
[dennis.c.ferguson%gmail.com@localhost]
Sent: Monday, September 10, 2012 11:48 AM
To: Scislowicz, Adam
Cc: Matt Thomas; port-powerpc%NetBSD.org@localhost
Subject: Re: Use of r31 on the powerpc/booke:mpc85xx architecture
On 10 Sep, 2012, at 12:11 , Scislowicz, Adam wrote:
> Yes, I was still using -fno-omit-frame-pointer when I experienced the issue,
> perhaps it is responsible. I will try to reproduce shortly with different
> build flags. Thank you for the response, I need to read the PPC ABI as I
> haven't yet which is why I was unsure of the register allocations and
> googling got me the incorrect answer the first time. Also I am not yet
> familiar with good practices regarding gcc flags for the P2020 or more
> generally powerpc. Most of my time has been spent on x86 and ARM thus far.
>
> Understood wrt stmw/lwm, was misreading the inline assembly wrt counting
> colons and PPC ASM wasn't fresh in my mind, context switch in progress ;)
Note, though, that it isn't perfectly clear what the PPC ABI is.
The original PPC ELF ABI supplement, e.g. here
http://refspecs.linuxbase.org/elf/elfspec_ppc.pdf
allowed r31 to optionally be dedicated to holding "environmental
pointers", whatever that is. I suspect the option you are using
makes gcc dedicate r31 to this, probably to make alloca() a bit
cheaper (likely at the expense of making everything which doesn't
use alloca() a bit more expensive).
This option was unique to that ABI spec. The (older) PowerOpen ABI,
used by AIX, specified r31 as a normal, callee-saved register, as
did the PowerPC "Embedded ABI" here:
http://www.freescale.com/files/32bit/doc/app_note/PPCEABI.pdf
More recently there has been work to unify the "desktop" and
"embedded" ABIs into one, e.g. here
https://www.power.org/resources/downloads/Power-Arch-32-bit-ABI-supp-1.0-Unified.pdf
and that work also removes the option of using r31 as anything
other than a normal, non-volatile register. And, finally, the
(related) 64 bit ELF ABI, here
http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html
has never special-cased r31 either.
So while the original PPC ELF ABI provided the option of using r31 for
a dedicated function this was probably a bad idea (as you've discovered
the PowerPC instruction set has several useful instructions which
are hardwired to use r31, so dedicating r31 to some function gets in the
way of using those instructions) and the option has been removed in newer
work. If -fno-omit-frame-pointer is making gcc special-case r31 then
you probably shouldn't use that flag. It causes gcc to generate code
that doesn't conform to the most recent version of the PPC ABI and
makes it harder to use certain features of the PPC instruction set.
Dennis Ferguson