Using trampolines but still getting a "Relocation overflow" linking error

Release v6.0.8 is relatively old.  While I don't know if your exact trampoline bug is fixed, I do know other trampoline bugs are fixed.  So, as a first step, I'd like you to try a newer compiler.  It would be ideal if you would try out the latest and greatest v7.3.0.  If that makes you nervous, then you should be comfortable with upgrading to the latest version on the v6.0.x release stream, which is v6.0.29.  Rationale for these recommendations is found in this wiki article.  How to download and upgrade the compiler is described in this wiki article.

Thanks and regards,

-George

Ok.  Thanks, I'll give a newer compiler a shot.

I just realized that with older C-compiler (v6.0.18 in this case) you can get the same linker error if the C-file containing the call-target function is missing from the compilation, but the corresponding include-file is there.

It really didn't "shout" about undefined symbols, but relocation overflow.

It may have to do with the fact that the call-target function should have been in a library that was used in the final linking that gave the error.

It seems that the latest 6.0.x compiler still contained this bug.  Moving to the latest 6.1.x compiler has resolved the relocation error.  Note, however, that the floating point math operations of the run time library changed significantly.  (more accurate, but produce slightly different results).

Hi,

Could you please let me know which trampoline bug are you referring above.

Our cusomter is also getting the same error with DM643x NDK DSP/BIOS.

The compiler version is little bit older "CGT v6.0.19".

------------------------------
error: relocation overflow occurred at address 0x000006b4 in section
'.text' of input file

The 21-bit PC-relative displacement 1048576 at this location is too large
to fit into the 21-bit PC-Relative field; the destination address is too
far away from the instruction.
------------------------------

We are not able to overceom the error even the
data memory model is set as --mem_model:data=far.

Is there any possiblity to overcome the relocation overflow error without
updating the compiler version?

Regards,
Prad.

By default the compiler should generate trampoline calls, so if you have not explicitly disabled this (--trampolines=off), then I don't think that there is a fool-proof workaround.  I had some limited success by artificially increasing generated code size to push things around so that the call(s) no longer fall directly on the 21-bit boundary.  Obviously, this was difficult to maintain, and the problem could re-emerge at any time.

...but it is sure that this is really a trampoline problem?

The error message can be misleading.

Thank you so much for the information.

The Trampolines are not disabled in our case, it is in the default(enabled) settings.
Currently our customer have updated to the latest compiler version of 6.0.x (i.e. v6.0.31).

And the data memory model is set to"--mem_model:data=far" with Trampolines enabled by default.

We are not sure if this problem is from the trampolines and
it is difficult for us update the compiler version to next version v6.1.x....

Could you please let us know if there is any way to find out
which exact part of the code is throwing such errors or any suggestions to troubleshoot this problem.

There are around 12 errors as shown below with --mem_model:data=far
and 7 errors with --mem_model:data=Far Aggregate.

>> error: relocation overflow occurred at address 0x0000018c in section
'.text' of input file
'C:\\..............................................................\Task.obj'.
The 29-bit PC-relative displacement 535669520 at this location is too large to fit into the 21-bit PC-Relative field;
the destination address is too far away from the instruction. You may need to add a mask to the assembly instruction
or use other target specific assembly features if you really only need the lowest 21 bits of this symbol.
Please see the section on Relocation in the Assembly User's Guide.

Best Regards
Prad.

Just a quick sanity check: do you have a single .text section larger than 0x1FFFFF, approximately?

I recall that if it's missing implementation, that should be seen in .map file.

Under:

GLOBAL SYMBOLS: SORTED ALPHABETICALLY BY Name

address    name
--------   ----

you would see the name, but something like "UNDEFINED" as the address.

With an older version of the compiler, I saw a situation that absolutely linked subroutines cause zero-trampolines.

The trampoline was generated, but the target address was not set.

Thank you..

Yes,  the map file shows there is only one .text.
.text -> 80060020(origin)  0048f040(Length)

and this is larger than 0x1FFFFF.

Best Regards
Prad.

Thank you turboscrew,

Yes, I found few symbols in the map file
which had "UNDEFED" in the address part
under both "GLOBAL SYMBOLS: SORTED BY Symbol Address" and
"GLOBAL SYMBOLS: SORTED ALPHABETICALLY BY Name" section.

Please let me know if there is suggestions on this.

Best Regards
Prad

Just check that the names are found in the implementation too.

For me it happened that the include-file containing a function name was included, but the .c-file was missing from the makefile.

That didn't give any error like "function missing", but that relocation error.

Prad1 said:

there is only one .text -> 80060020(origin)  0048f040(Length)

Because your .text section is so large, it may be the case that the trampoline is too far away from the original call site.

The linker can only add trampolines at the end of the .text section. The original call site is still a 21-bit PC-relative branch, and so it can't branch past all of that 0x48f040 length to reach the trampoline.  The trampoline itself is fine, because it does not use the 21-bit PC-relative branch, it uses the full 32 bits in a register.

You can try splitting the .text section into several output sections in the linker command file.  Then, the linker will have the opportunity to add trampolines in several places.

    .text:hello { hello.obj(.text) } > PMEM
    .text:rts { rts*.lib<printf.obj>(.text) } > PMEM
    .text       >       PMEM