This is the mail archive of the binutils@sourceware.org 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]
Other format: [Raw text]

Re: tic6x: relocation truncated to fit: R_C6000_PCR_S21


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


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