This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Linking very large application with GCC trunk on powerpc-linux leads to relocation error of crtbegin/end.o
- From: Laurent GUERBY <laurent at guerby dot net>
- To: Alan Modra <amodra at bigpond dot net dot au>
- Cc: gcc <gcc at gcc dot gnu dot org>, Peter Bergner <bergner at vnet dot ibm dot com>, geoffk <geoffk at geoffk dot org>, dje at watson dot ibm dot com
- Date: Mon, 16 Jun 2008 19:50:45 +0200
- Subject: Re: Linking very large application with GCC trunk on powerpc-linux leads to relocation error of crtbegin/end.o
- References: <1213615678.18723.59.camel@localhost> <20080616140649.GA21443@bubble.grove.modra.org>
- Reply-to: laurent at guerby dot net
On Mon, 2008-06-16 at 23:36 +0930, Alan Modra wrote:
> On Mon, Jun 16, 2008 at 01:27:58PM +0200, Laurent GUERBY wrote:
> > Hi,
> >
> > When linking a very large (> 100MB executable) application on
> > powerpc-linux with trunk we get linker errors:
> >
> > .../lib/gcc/powerpc-unknown-linux-gnu/4.4.0/crtbegin.o:(.fini+0x0):
> > relocation truncated to fit: R_PPC_REL24 against `.text'
> > .../lib/gcc/powerpc-unknown-linux-gnu/4.4.0/crtend.o:(.init+0x0):
> > relocation truncated to fit: R_PPC_REL24 against `.text'
> >
> > The application itself is compiled with -mlongcall,
> > would adding -mlongcall to crtstuff.c Makefile rule help here?
>
> It ought to. You could also try GNU ld's --relax option, which might
> also allow you to dispense with -mlongcall for your app.
You mean adding to config/rs6000/t-linux64 and create
config/rs6000/t-linux with:
CRTSTUFF_T_CFLAGS += -mlongcalls
CRTSTUFF_T_CFLAGS_S += -mlongcalls
Would a patch with this be approved on trunk?
I noticed another target config/xtensa/t-elf which has something very
close:
# Build CRT files and libgcc with the "longcalls" option
CRTSTUFF_T_CFLAGS += -mlongcalls
CRTSTUFF_T_CFLAGS_S += -mlongcalls
TARGET_LIBGCC2_CFLAGS += -mlongcalls
Is the "TARGET_LIBGCC2_CFLAGS" necessary as well?
> > If no, what is the proper solution GCC-wise?
>
> I'll note that this problem is exacerbated by the fact that crtbegin.o
> defines the destructor function run from .fini and crtend.o defines
> the constructor run from .init. It really should be the other way
> around, since this arrangement results in maximmum offset branches,
> from the .init section located before .text to a function at the end
> of .text, and from the .fini section located after .text to a function
> at the beginning of .text.
Too arcane for me :). Let's hope someone else can comment on this.
Thanks for your help, I'll get some results tomorrow.
Laurent