This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: %pc relative addressing of string literals/const data
Alan Modra <amodra@gmail.com> wrote on 2010/10/06 00:19:26:
>
> On Tue, Oct 05, 2010 at 11:40:11PM +0200, Joakim Tjernlund wrote:
> > yes, but this could be a new PIC mode that uses a new better
> > PIC mode for everything. Especially one that doesn't require each function
> > to calculate the GOT address in the function prologue(why is that so?)
>
> The new ppc64 -mcmodel=medium support does give you pic access to
> locals.
>
> -fPIC -O2 without hidden
> .LC0:
> .tc x[TC],x <-- compiler managed GOT entries
> .LC1:
> .tc y[TC],y
> [snip]
> .L.foo:
> addis 11,2,.LC0@toc@ha
> addis 9,2,.LC1@toc@ha
> ld 11,.LC0@toc@l(11)
> ld 9,.LC1@toc@l(9)
> lwz 3,0(11)
> lwz 0,0(9)
> add 3,3,0
> extsw 3,3
> blr
>
> -fPIC -O2 with hidden pragma
> .L.foo:
> addis 11,2,x@toc@ha
> addis 9,2,y@toc@ha
> lwz 3,x@toc@l(11) <-- TOC/GOT pointer relative
> lwz 0,y@toc@l(9)
> add 3,3,0
> extsw 3,3
> blr
>
> x@toc is equivalent to @GOTOFF on other processors.
Don't have nor know much about ppc64 as I use ppc32 :(
Would it be possible to have this for ppc32 too?
Perhaps small patch is needed(I am on gcc 4.4.4)?
Just to make sure, this works for an executable even when
link address != run address and the GOT hasn't been adjusted to
the running address?
This would be very good news for u-boot as there is a need for
link once, burn to flash anywhere and just run.
Oh, one thing more, would it be possible to have -mrelocatable work
-fpic too? We need the fixups, but as -fpic produces smaller code it would
be nice if the -fpic -mrelocatable combo works.
Jocke