This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Make check failure: ARM in ld-bootstrap/bootstrap.exp...


>/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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]