bugAVR C Runtime Library - Bugs: bug #33698, Explicit use of RJMP/RCALL can...

 
 

bug #33698: Explicit use of RJMP/RCALL can cause "relocation truncated to fit: R_AVR_13_PCREL" linker error

Submitted by:  Georg-Johann Lay <gjlayde>
Submitted on:  Sat 02 Jul 2011 10:12:32 PM UTC  
 
Category: LibrarySeverity: 3 - Normal
Priority: 9 - ImmediateItem Group: Unknown
Status: Need InfoPercent Complete: 0%
Assigned to: NoneOpen/Closed: Open
Release: 1.7.1Fixed Release: None

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Tue 21 Jan 2014 11:36:11 AM UTC, comment #16:

What's the state of this? It seems to cause trouble when using LTO (-flto).
Any known workarounds?

Martin Nowak <dawg>
Sun 03 Feb 2013 04:17:20 PM UTC, comment #15:

FYI, if the compiler is configured with --with-avrlibc, it will omit functions from libgcc that are known to be provided by libm.a.

This is supported in avr-gcc 4.7.2 and up, cf. http://gcc.gnu.org/PR54461

However, I still think AVR-LibC needs to be fixed because sections are not sorted by their names.

Georg-Johann Lay <gjlayde>
Fri 16 Nov 2012 06:29:21 PM UTC, comment #14:

Gentlemen, a solution to this issue needs to be found and implemented.

First, are we certain that there is an underlying problem that actually generates wrong code?

Second, do we have tests (in some test suite) that actually fail because of this issue?

Third, do we have a full list of source code modules & functions that are affected? i.e. What do we need to change?

Eric Weddington <arcanum>
Project Administrator
Sun 05 Aug 2012 05:05:53 PM UTC, comment #13:

More modules are:
and maybe even more.

Georg-Johann Lay <gjlayde>
Sun 05 Aug 2012 04:53:18 PM UTC, comment #12:

./libm/fplib/fp_rempio2.S is also affected, see

Georg-Johann Lay <gjlayde>
Sun 19 Feb 2012 10:06:05 AM UTC, comment #11:

Dmitry Xmelkov:

> The math library is not designed to use float routines
> from libgcc. The float routines of libm are extended in
> comparison to standart ones. For example, the 40-bit
> float and bit T are widely used (32-bit mantissa).
> Normaly, the libm resolves all links internaly. The usage of
> libgcc from libm is error.


The problem is a design flaw in avr-libc. It never should
have implemented any routines that support language
kernel like base arithmetic, for example float a*b.

That stuff belongs to libgcc, but for whatever reasons
people dropped their code at libc and not at libgcc.
libc greedily accepted it and now the mess is here and cast
into stone because the original authors are gone and no one
is inclined to shift the code to the place it belongs to:
libgcc. See http://gcc.gnu.org/PR28718

I thought about a configure gadget for GCC that excludes
libgcc's math routines that are inteded to be "overridden"
by libc's routines. But that would couple gcc and libc more
closely and make them depend on each other. And it would
be yet another hack that suppots a design flaw.

> Alas, there is no checking of this. Sometimes the
> 'relocation truncuted to fit' is such protection :-).
> If linking is classic (libm is first), explicit use of
> RJMP/RCALL is OK, as libm is small.
> In practice, this works.


I see also crashes for C programs in the GCC test suites
with the error and lm at the right place.

libm is not a monolithic chunk of code just as libgcc is not
monolithic. Thus, even though libm is small as a whole, there
is no guarantee that its chunks are located close together.

That's why I though about SORT directive in ld-script.

> I will think how to untangle this ball. Not quickly.


As said, the right place is libgcc.

Georg-Johann Lay <gjlayde>
Sun 19 Feb 2012 06:12:05 AM UTC, comment #10:

The math library is not designed to use float routines from
libgcc. The float routines of libm are extended in comparison
to standart ones. For example, the 40-bit float and bit T are widely used (32-bit mantissa).

Normaly, the libm resolves all links internaly. The usage of
libgcc from libm is error. Alas, there is no checking of this.
Sometimes the 'relocation truncuted to fit' is such protection :-).

If linking is classic (libm is first), explicit use of
RJMP/RCALL is OK, as libm is small. In practice, this works.

The problems are C++ and usage float operations in libc (float
printing and scanning).

I will think how to untangle this ball. Not quickly.

Dmitry Xmelkov <dmix>
Project Administrator
Fri 17 Feb 2012 02:33:23 PM UTC, comment #9:

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

Georg-Johann Lay <gjlayde>
Thu 16 Feb 2012 01:47:37 PM UTC, comment #8:

Hi Johann

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

> 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?

I don't know much about the silicon bug. I'll read about it.

Vidya Praveen <childbear>
Thu 16 Feb 2012 11:10:09 AM UTC, comment #7:

> IMO, I think the cleaner solution is to:
>
> 1. Improve the definition of XCALL/XJMP - at present
> it's defines call/jmp when _AVR_MEGA_ and rjmp/rcall
> otherwise. We need to correct this.


That won't catch all cases because sources use RJMP directly.
See the initial post for examples.

> 2. Like Jan Waclawek mentioned, let the linker relaxation
> optimize it, rather than changing the linker script to
> keep the math functions closer (even if we do, i wonder if
> it's going to solve the problem completely)


Keeping functions together and knowing that RCALL is always
legal can simplify the sources. There is a silicon bug that
obsoletes call-skip sequences.

For example, in libgcc we see code like the following:

#ifdef _AVR_ERRATA_SKIP_JMP_CALL_
;; Some cores have problem skipping 2-word instruction
tst A0
brmi 1f
#else
sbrs A0, 7
#endif /* _AVR_HAVE_JMP_CALL_ */
XJMP __fmul
1: XCALL __fmul

This must not rely on linker relaxation.

If, however, binutils ensured that functions in
section .text.libgcc and any .text.libgcc.foo are close
together, the snip above could be simplified as

sbrs A0, 7
XJMP __fmul
XCALL __fmul

For avr-libc this means that replacing RCALL/RJMP with
XCALL/XJMP must be done carefully if the instruction
is a skip's payload (SBRS, SBRC, SBIS, SBIC, CPSE).

Georg-Johann Lay <gjlayde>
Wed 15 Feb 2012 06:48:08 AM UTC, comment #6:

IMO, I think the cleaner solution is to:

1. Improve the definition of XCALL/XJMP - at present it's defines call/jmp when _AVR_MEGA_ and rjmp/rcall otherwise. We need to correct this.

2. Like Jan Waclawek mentioned, let the linker relaxation optimize it, rather than changing the linker script to keep the math functions closer (even if we do, i wonder if it's going to solve the problem completely)

Is anyone already working on this?

Vidya Praveen <childbear>
Tue 27 Sep 2011 05:54:45 PM UTC, comment #5:

> I think that all math libraries are put into their own
> linker section, and so will be close enough to use
> rcall/rjmp, but this would have to be verified.


So ./ld/scripttempl/avr.sc will be arranged to sort .text* input sections?

Georg-Johann Lay <gjlayde>
Tue 27 Sep 2011 02:29:57 PM UTC, comment #4:

It appears to me that most of those 135 places (those which rcall to external label, perhaps indentified by the _U() macro) are potential errors, e.g. http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=108109 and many more.

But changing them to "regular" jumps, and then using -relax if minimal code is desired, should be an acceptable solution.

I'd say this has been already discussed, see http://lists.gnu.org/archive/html/avr-gcc-list/2011-06/msg00025.html and other posts of that thread.

Jan Waclawek <wek>
Mon 26 Sep 2011 10:36:54 PM UTC, comment #3:

There's 135 places where 'rcall' is used just in libm/fplib/*.S. I don't think that all of these are in error...

I think that all math libraries are put into their own linker section, and so will be close enough to use rcall/rjmp, but this would have to be verified.

Eric Weddington <arcanum>
Project Administrator
Mon 26 Sep 2011 07:01:25 PM UTC, comment #2:

Hi Eric,

XJMP/XCALL look reasonable, but I am not familiar with avr-libc and don't know what is best practice here.

./libm/fplib/log.S is the only module that I am aware of. Maybe there are others that are not as common as log like gamma or bessel, I really don't know...

Georg-Johann Lay <gjlayde>
Mon 26 Sep 2011 03:51:15 PM UTC, comment #1:

Hi Johann,

Do you have a complete list of which parts need fixes?

And what is your recommended fix? There's the XJMP/XCALL macro in common/macros.inc.

Eric Weddington <arcanum>
Project Administrator
Sat 02 Jul 2011 10:12:32 PM UTC, original submission:

Some assembler source files in avr-libc contain explicit RJMP/RCALL instructions even for devices > 8KiB. It's by no means obvious that offsets to jump/call targets are in the range of RJMP/RCALL.

One example is

./libm/fplib/log.S (revision=2191):

http://svn.savannah.nongnu.org/viewvc/trunk/avr-libc/libm/fplib/log.S?revision=2191&root=avr-libc&view=markup

Georg-Johann Lay <gjlayde>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #26323:  bug_confirmation.txt added by demiurg_spb (6kB - text/plain - confirm )

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by dawg (Posted a comment)
  • -unavailable- added by demiurg_spb (Updated the item)
  • -unavailable- added by dmix (Posted a comment)
  • -unavailable- added by childbear (Posted a comment)
  • -unavailable- added by wek (Posted a comment)
  • -unavailable- added by arcanum (Posted a comment)
  • -unavailable- added by gjlayde (Submitted the item)
  •  

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 16 Nov 2012 06:29:21 PM UTCarcanumPriority5 - Normal=>9 - Immediate
    Mon 06 Aug 2012 06:13:48 AM UTCdemiurg_spbAttached File-=>Added bug_confirmation.txt, #26323
    Mon 26 Sep 2011 03:51:30 PM UTCarcanumStatusNone=>Need Info

    Back to the top


    Powered by Savane 3.1-cleanup