[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[avr-libc-dev] [bug #33698] Explicit use of RJMP/RCALL can cause "reloca
[avr-libc-dev] [bug #33698] Explicit use of RJMP/RCALL can cause "relocation truncated to fit: R_AVR_13_PCREL" linker error
Fri, 17 Feb 2012 14:33:24 +0000
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52) Gecko/20100506 SUSE/3.5.10-0.1.2 Firefox/3.5.10
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
I don't think you really want to do *that*!
It's 1000s of changes throughout the sources, most of which are not really
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
You cannot write
and let the assembler relax it to
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
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:
Nachricht geschickt von/durch Savannah