This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [ARM] Use r9 or r10 as the PIC register only when TARGET_32BIT
- From: Paul Brook <paul at codesourcery dot com>
- To: gcc-patches at gcc dot gnu dot org
- Cc: Jie Zhang <jie at codesourcery dot com>
- Date: Wed, 12 Jan 2011 12:52:20 +0000
- Subject: Re: [ARM] Use r9 or r10 as the PIC register only when TARGET_32BIT
- References: <4CA0D4D5.50503@codesourcery.com>
> 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.