This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Gcc 3.2.1 arm-elf apcs32 register mishandling
- From: Ryan Pipkin <ryan dot pipkin at inet dot com>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 28 Apr 2003 18:11:17 -0500
- Subject: Gcc 3.2.1 arm-elf apcs32 register mishandling
Can someone please verify that this is a problem. Referring to the
APCS a0 - a3, and ip are used between procedure calls. Therefore the
local routine cannot assume any values for these registers beyond a
branch and link. When used again they must be loaded again. I have
included two samples from a dissassembled object file in which it looks
like they are being used incorrectly. I have tested on 3 compiler
versions as indicated.
Here are the compiler options used:
-c -nostdinc -O3 -mcpu=xscale -msoft-float -mapcs-32 -fno-rtti
-fno-exceptions -fsigned-char -fno-builtin -b arm-unknown-elf -V 3.2.1
Using 2.96 is not an option due to a stack corruption problem. I only
included it in these results for comparision.
3.2.1 (rebuilt from source --target=arm-unknown-elf)
d8: e50bc02c str ip, [fp, -#44]
dc: ebfffffe bl 0 <_ZN12PciXScaleDevC2Ej> (resolves to
strncpy)
e0: e289e09c add lr, r9, #156 ; 0x9c
e4: e58ce21c str lr, [ip, #540]
3.1 (GNUPRO xscale-020523)
d8: e50b302c str r3, [fp, -#44]
dc: ebfffffe bl 0 <_ZN12PciXScaleDevC2Ej> (resolves to
strncpy)
e0: e289a09c add sl, r9, #156 ; 0x9c
e4: e583a21c str sl, [r3, #540]
Same problem different register.
2.96 (GNUPRO xscale-010827)
I could not find any instance of r0,r1,r2,r3,ip being used with
assumed value after a bl call.
The source rther investigation wCan someone please verify that this is a
problem. Referring to the APCS a0 - a3, and ip are used between
procedure calls. Therefore the local routine cannot assume any values
for these registers beyond a branch and link. When used again they must
be loaded again. I have included two samples from a dissassembled
object file in which it looks like they are being used incorrectly. I
have tested on 3 compiler versions as indicated.
Here are the compiler options used:
-c -nostdinc -O3 -mcpu=xscale -msoft-float -mapcs-32 -fno-rtti
-fno-exceptions -fsigned-char -fno-builtin -b arm-unknown-elf -V 3.2.1
Using 2.96 is not an option due to a stack corruption problem. I only
included it in these results for comparision.
3.2.1 (rebuilt from source --target=arm-unknown-elf)
d8: e50bc02c str ip, [fp, -#44]
dc: ebfffffe bl 0 <_ZN12PciXScaleDevC2Ej>
e0: e289e09c add lr, r9, #156 ; 0x9c
e4: e58ce21c str lr, [ip, #540]
3.1 (GNUPRO xscale-020523)
d8: e50b302c str r3, [fp, -#44]
dc: ebfffffe bl 0 <_ZN12PciXScaleDevC2Ej>
e0: e289a09c add sl, r9, #156 ; 0x9c
e4: e583a21c str sl, [r3, #540]
Same problem different register.
2.96 (GNUPRO xscale-010827)
I could not find any instance of r0,r1,r2,r3,ip being used with
assumed value after a bl call.
What I see is a C++ function calling a C function. The problem seems to
go away when I use the -mno-apcs-frame option.
My question is: What is the difference in register usage between
apcs-frame and no-apcs-frame?
Is there a problem with apcs frames here.
I am still looking for references to the apcs setup in gcc, but any help
would be greatly appreciated.
* Gcc 3.2.1 xscale defaults to -mapcs-frame
With -mno-apcs-frame option.
_ZN12PciXScaleDevC2Ej:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
stmfd sp!, {r4, r5, r6, r7, r8, r9, sl, fp, lr}
strncpy:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
---------------------
With -mapcs-frame
_ZN12PciXScaleDevC2Ej:
@ args = 0, pretend = 0, frame = 4
@ frame_needed = 1, uses_anonymous_args = 0
mov ip, sp
stmfd sp!, {r4, r5, r6, r7, r8, r9, sl, fp, ip, lr, pc}
strncpy:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0