This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: Make check failure: ARM in ld-bootstrap/bootstrap.exp...
- To: scottb <scottb@netwinder.org>
- Subject: Re: Make check failure: ARM in ld-bootstrap/bootstrap.exp...
- From: Philip Blundell <Philip.Blundell@pobox.com>
- Date: Sat, 04 Sep 1999 00:08:06 +0100
- cc: binutils mailing list <binutils@sourceware.cygnus.com>
>/usr/lib/libc.a(vfprintf.o): In function `_IO_vfprintf':
>/usr/src/redhat/BUILD/glibc-2.1.2/stdio-common/vfprintf.c:1551:
>relocation truncated to fit: R_ARM_PC24
>_pthread_cleanup_pop_restore
Those are unresolved weaks that point to 0. The ARM GNU/Linux ABI puts
programs at 0x02000000 (0x00800000 words) by default, which means that
address 0 is too far away to be reached by a 24-bit signed displacement.
Previously the linker would just silently generate branches to the wrong
address. This never really bothered me because any program that jumps to
an unresolved symbol is going to crash anyway - it didn't seem important
whether it succeeded in actually jumping to address 0 or not. But this
change:
1999-08-11 Robin Farine <advanc@dial.eunet.ch>
* elf32-arm.h (elf32_arm_final_link_relocate): Check for overflow
in R_ARM_PC24 relocs.
apparently made the linker rather stricter about this behaviour which is why
we are now seeing errors.
Something that has been on my list of things to do for a while is teaching the
linker how to synthesize a PLT entry when a branch target is out of range. I
think this would make this problem go away again. Alternatively, a cheap hack
to suppress the range checking when the target is an unresolved weak might
also get things going.
p.