[Gcl-devel] Re: relocation overflow

[Daniel Jacobowitz]

On Thu, Nov 21, 2002 at 01:53:07PM -0500, Camm Maguire wrote:
> Greetings, and thanks for your reply!
> 
> Geoff Keating <geoffk@geoffk.org> writes:
> 
> > > Cc: Daniel Jacobowitz <drow@mvista.com>, Alan Modra <amodra@bigpond.net.au>,
> > >    gcl-devel@gnu.org, binutils@sources.redhat.com
> > > From: Camm Maguire <camm@enhanced.com>
> > > Date: 20 Nov 2002 21:45:23 -0500
> > 
> > > Greetings, and thanks for your reply!
> > > 
> > > Geoff Keating <geoffk@geoffk.org> writes:
> > > 
> > > > Daniel Jacobowitz <drow@mvista.com> writes:
> > > > 
> > > > > On Wed, Nov 20, 2002 at 12:01:59PM -0500, Camm Maguire wrote:
> > 
> > > > > PowerPC GCC doesn't seem to have a long-calls option, so you're just
> > > > > out of luck if you can't fit things in 16MB.  Trampolines may be the
> > > > > way to go.
> > > > 
> > > > The way this is normally done, for programs that load arbitrary
> > > > modules, is that each module is a .so file, is built with -fpic, and
> > > > is loaded using the dlsym functions.  Then the limit is 32Mb per
> > > > module, and you can have as many modules as your address space can
> > > > fit; cross-module calls happen through a PLT which can perform long
> > > > jumps.
> > > 
> > > OK, when I first read this, I thought that -fPIC would eliminate 24bit
> > > relocs.  I was mistaken, and have just verified that the reloc
> > > overflows are different, but still present, when adding -fPIC.  On
> > > rereading this, it appears as though the dlym code has trampolines to
> > > handle long calls on 24bit relocs.  Maybe I should look here.
> > 
> > Perhaps you are trying to load .o files, not .so files?  There should
> > be no *24 relocs in a .so file if all its contents are built with
> > -fpic or -fPIC.
> 
> OK, this is what I thought you meant the first time.  Unfortunately,
> this does not seem to be the case:
> 
> camm@voltaire:~/gcl-2.5.0.cvs20020625/o$ gcc -c -Wall -DVOL=volatile -fsigned-char -fwritable-strings -pipe -fPIC main.c -o main.o
> camm@voltaire:~/gcl-2.5.0.cvs20020625/o$ objdump -x main.o |grep 24
> 00000024       O *COM*	00000004 Cnil_body
> 00000024       O *COM*	00000004 Dotnil_body
> 00000024       O *COM*	00000004 Ct_body
> 00002460 g     F .text	00000084 siLinitialization_failure
> 000024e8 g     F .text	00000054 Lidentity
> 00000048 R_PPC_PLTREL24    setbuf
> 00000058 R_PPC_PLTREL24    setbuf
> ...
> 00000024 R_PPC_ADDR32      system_directory
> 000000b4 R_PPC_ADDR32      .data+0x00000024
> 
> Perhaps I need to pass each module through ld -shared too?

Yes.  That's an unlinked object, not a shared object.  Don't play the
Linux kernel's nightmare game with loading .o files unless you
absolutely must...

(I think this is one of the special cases where you can use ld -shared
instead of gcc -shared, but if gcc -shared works for you it is
definitely preferable.)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer