This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
tic6x: relocation truncated to fit: R_C6000_PCR_S21
- From: Timon ter Braak <timon at terbraak dot org>
- To: binutils at sourceware dot org
- Date: Thu, 07 Feb 2013 18:29:15 +0100
- Subject: tic6x: relocation truncated to fit: R_C6000_PCR_S21
Hi,
I have a toolchain for the TI C64x DSP with binutils 2.23.1. It
generates valid executables for 'toy examples', but for a larger (but
still reasonable) code size, I get relocation problems:
/target/lib/gcc/c6x-uclinux/4.7.2/crtbegin.o:(.fini+0x0): relocation
truncated to fit: R_C6000_PCR_S21 against `.text'
/target/lib/gcc/c6x-uclinux/4.7.2/crtend.o:(.init+0x0): relocation
truncated to fit: R_C6000_PCR_S21 against `.text'
/target/lib/gcc/c6x-uclinux/4.7.2/libgcc.a(emutls.o): In function
`emutls_init':
/src/gcc-4.7.2/libgcc/emutls.c:88:(.text+0x64): relocation truncated to
fit: R_C6000_PCR_S21 against symbol `abort' defined in .plt section in
/target/c6x-uclinux/libc/usr/lib/crt1.o
The errors relate to the GCC parts required for my application, and not
my application itself.
I am not an expert in this area, but it seems relative relocations are
chosen for the object files, while later on the reserved bits for the
relative address are insufficient.
To my understanding, relative relocations are used for efficiency
purposes; ie. less instructions.
Is there any way I could force the compiler/linker/assembler to use an
absolute-based relocation instead of the relative one below?
/bfd/elf32-tic6x.c: R_C6000_PCR_S21
Or, alternatively, should I look into GCC itself instead of binutils?
-- Timon