diff mbox

[ARM] Use r9 or r10 as the PIC register only when TARGET_32BIT

Message ID 4CA0D4D5.50503@codesourcery.com
State New
Headers show

Commit Message

Jie Zhang Sept. 27, 2010, 5:31 p.m. UTC 
I'm investigating

FAIL: gcc.target/arm/pr42495.c (internal compiler error)
FAIL: gcc.target/arm/pr42495.c (test for excess errors)
FAIL: gcc.target/arm/pr42495.c scan-rtl-dump hoist "PRE/HOIST: end of bb 
.* copying expression": dump file does not exist

for arm-uclinuxeabi target. The cause of the ICE is because GCC uses r9 
as the PIC register for thumb1 code. This patch should fix it.

The original line of the code is several years old. It might have been 
broken for a long time. It could be no one use -fpic on ARM uClinux or 
-msingle-pic-base on other arm targets. Or I missed something.

Does this patch look OK? This patch fixes the above FAILs, but I have 
not fully tested it. I will do the regression testing with some other 
patches in a few days.


Regards,

Comments

Paul Brook Jan. 12, 2011, 12:52 p.m. UTC | #1 
> The original line of the code is several years old. It might have been
> broken for a long time. It could be no one use -fpic on ARM uClinux or
> -msingle-pic-base on other arm targets. Or I missed something.

AFAIK arm-uclinux only has a relatively small number of users and I'd bet most 
of those don't use PIC[1].  It's entirely possible you're the first person to 
notice and care that -mthumb -fPIC broke[2].  -msingle-pic-base is an ABI 
changing option, so specifying it manually (rather than inheriting your OS 
defaults) almost certainly means you're doing something else wrong.

> Does this patch look OK?

No.

The whole point of -msingle-pic-base is to use a fixed base register for data 
addressing (in EABI terms, this is SB-relative addressing).  The pic base 
register is specified by the ABI.  The fact that legacy targets can't decide 
whether to use r9 or r10 is probably broken, but I find it hard to care about 
such targets.

i.e. we really do want to use r9 as the pic base register.  You need to fix 
whatever broke, rather than unilaterally picking a more convenient register.

Paul

[1] One of the main motivations for PIC is shared libraries.  However arm-
uclinux shared library support is extremely limited and crufty, if it works at 
all.  Also, it is not possible to mix PIC and non-PIC code, so you either need 
to flip the default or build multilibs.
[2] Last time I checked this is just one of a long list of things that didn't 
work out of the box on arm-uclinux.
diff mbox

Patch


	* config/arm/arm.c (arm_option_override): Use r9 or r10
	as the PIC register only when TARGET_32BIT.

Index: config/arm/arm.c
===================================================================
--- config/arm/arm.c	(revision 164646)
+++ config/arm/arm.c	(working copy)
@@ -1868,7 +1868,7 @@  arm_option_override (void)
 
   /* If stack checking is disabled, we can use r10 as the PIC register,
      which keeps r9 available.  The EABI specifies r9 as the PIC register.  */
-  if (flag_pic && TARGET_SINGLE_PIC_BASE)
+  if (flag_pic && TARGET_SINGLE_PIC_BASE && TARGET_32BIT)
     {
       if (TARGET_VXWORKS_RTP)
 	warning (0, "RTP PIC is incompatible with -msingle-pic-base");