[avr-libc-dev] [bug #33698] Explicit use of RJMP/RCALL can cause "relocation truncated to fit: R_AVR_13_PCREL" linker error

[Georg-Johann Lay]

Follow-up Comment #9, bug #33698 (project avr-libc):

>> That won't catch all cases because sources use RJMP directly.
>> See the initial post for examples. 
> 
> I wanted to mean that if we replace all the rjmp/rcalls to
> XJMP/XCALLs...

I don't think you really want to do *that*!

It's 1000s of changes throughout the sources, most of which are not really
needed.

Moreover, unconditionally using JMP if available will induce further code
changes because unrelated branches become out of reach. Notice that in avr
tools, the linker can relax long->short but neither linker or assembler can do
other way round (at least not for avr) so that all branches must fit in branch
scope:

You cannot write
  breq foo
and let the assembler relax it to
  brne 0f
  [r]jmp foo
  0:
like on some other binutils implementation. Thus, if the BREQ becomes out of
scope because it jumps over a now longer offset (because not really needed
intermediate RJMP->XJMP change) you must patch BREQ foo, too.

This means that replacing *all* RJMP by XJMP is *much* work and might reduce
performance in places you'd never guess.

But that's up to lib maintainers, of course...

>> Keeping functions together and knowing that RCALL is always
>> legal can simplify the sources. 
> 
> But I believe that we should keep the linker scripts as 
> generic as possible. Well, that's jus my opinion :)
> 
> "If we know that RCALL is always legal", then yes.
> But how do we know/ensure?

Suppose code from avr-gcc's libgcc.  It has several functions to implement
FMUL[S[U]] if the core does not supply them. FMULS calls FMUL, and all
function involved are in section

.text.libgcc.fmul

All functions contributing to .text.libgcc.fmul fit into 8KiB of flash and
could use RCALL.

But: There is no SORT for .text.libgcc.* so that different inpu sections even
with the same name might be located far away and a RCALL might NOT be enough.


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?33698>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/