tic6x: relocation truncated to fit: R_C6000_PCR_S21

Timon ter Braak timon@terbraak.org
Fri Feb 15 08:05:00 GMT 2013


On 02/14/2013 02:32 PM, Joseph S. Myers wrote:
> On Thu, 14 Feb 2013, nick clifton wrote:
> You can't generally replace sequences by smaller ones, or really
> manipulate them at all in the assembler or linker, because of the exposed
> pipeline.  The most plausible approach is for the linker to make long
> branches branch to a veneer the linker generates.  But it would be odd to
> have more than 4MB of code on C6X, so my first suspicion remains that
> actually you have something wrong with how the linker is laying out code,
> and that you need to fix that problem so that the < 4MB of real code is
> all contiguous in the address space as it should be - and you don't need
> to implement long-branch veneers.
>

While indeed not the typical use-case, I do need ELF objects (either
static executables, or shared libs) that exceed the 4MB limit. I
specifically am trying to support the Go runtime on this architecture.

-----

/c6x-uclinux/src/stage3-gcc/./gcc/crtbeginS.o:(.fini+0x0): relocation
truncated to fit: R_C6000_PCR_S21 against `.text'
/c6x-uclinux/src/stage3-gcc/./gcc/crtendS.o:(.init+0x0): relocation
truncated to fit: R_C6000_PCR_S21 against `.text'
.libs/go-make-slice.o: In function `__go_make_slice2':
/c6x-uclinux/src/gcc-4.7.2/libgo/runtime/go-make-slice.c:40:(.text+0x70): relocation 

truncated to fit: R_C6000_PCR_S21 against symbol `__c6xabi_divu' defined
in .text section in /c6x-uclinux/src/stage3-gcc/./gcc/libgcc.a(_udivsi3.o)
...



More information about the Binutils mailing list