View Bug Activity | Format For Printing
As described in GCC bugzilla: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523 And discussed on gcc-patches here: http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00409.html The first stage of building trunk (4.4) GCC fails on arm-linux-gnueabi native with the following link time error: libbackend.a(cfgcleanup.o): In function `VEC_int_base_quick_insert': /n/50/guerby/build-143365/gcc/../../trunk/gcc/vecprim.h:26: relocation truncated to fit: R_ARM_CALL against symbol `memmove@@GLIBC_2.4' defined in .plt section in /usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../crti.o ... This error does not go away with --stub-group-size=1 or 1024, combined or not with --relax. I tried ld from binutils 2.19 and CVS "2.19.51.20090114" with the same results. Any idea on what to try?
Hi Laurent, Since --stub-group-size=1 is the default, it is not surprising that it made no difference. --stup-group-size=1024 tells the linker to process 1024 input sections before trying to insert a stub section, which is very unlikely to help you given that you problem is that the input sections are so large. Please could you try --stub-group-size=-1, which tells the linker to place stub sections before the sections that need them. If that does not work, please try --stub-group-size=2 which tells the linker to place stub sections both before and after input sections that need them, and to group the input sections into units of 2. If neither of those options work, you could try some larger positive values (eg 4, 8, 16) but in the end this is a heuristic to find a sweet spot to place branch stubs, not a guarantee of successful linking. Cheers Nick PS. Did you try compiling your stage 1 boostrap with -mlong-calls ? This should work around the 32Mbyte offset limit of the BL instruction by making gcc load the address of a function to be called into a register first.
STAGE1_CFLAGS=-O1 or --enable-stage1-checking=release are enough to workaround the linker limitation for GCC stage1. I'll try your suggestions when I get my ARM machine back online.
I think there is a bug in the code that inserts the stubs: it skips .plt entries, but it seems it should not. Once your ARM machine is back, I'll try to fix it.
Hi Christophe, I've seem some commits related to this issue, is it fixed or a is a piece still missing? Thanks in advance.
Hi Laurent, Currently, there is still a patch missing, but it has just been approved today, so I hope this issue can finally be closed soon.
The patch has now been committed (http://sourceware.org/ml/binutils/2009-04/msg00317.html). Laurent, can I let you confirm that your problem is really solved?
Yep I'll test CVS binutils tomorrow on gcc55.
Bootstrap of current trunk GCC on arm-linux (gcc55) was successful without any special configure or BOOT_CFLAGS option with CVS binutils 20090423, so this issue is fixed, thanks!