This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]