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

 
 

You are not allowed to post comments on this tracker with your current authentication level.

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

Submitter:  Georg-Johann Lay <gjlayde>
Submitted:  Sat 02 Jul 2011 10:12:32 PM UTC
   
 
Category:  Library Severity:  4 - Important
Priority:  9 - Immediate Item Group:  Unknown
Status:  Fixed Assigned to:  None
Percent Complete:  0% Open/Closed:  Open
Release:  1.7.1 Fixed Release:  None

Jump to the original submission

Thu 09 Apr 2015 08:14:11 AM UTC, comment #23: 
Pitchumani <pitchumani>
Group Member
Wed 08 Apr 2015 11:38:17 AM UTC, comment #22: 

@Martin, Changes for ctype.S is not complete.

Functions in ctype.S are included in separate assembly files conditionally (e.g. libc/stdlib/ispunct.S) to create object files for each function in ctype.S.

Attached patch for ctype.S (rjmp-ctype.patch) that changes all eligible rjmp/rcall to XJMP/XCALL.

(file #33593)

Pitchumani <pitchumani>
Group Member
Wed 08 Apr 2015 09:46:57 AM UTC, comment #21: 

Ran gcc regression tests with avrtest simulator (atmega1280 and atxmega128a3). No new fails/ errors found.

Pitchumani <pitchumani>
Group Member
Fri 27 Mar 2015 05:27:29 PM UTC, comment #20: 

Updated the patch to also fix ctype.S.


(file #33469)

Martin Nowak <dawg>
Fri 27 Mar 2015 05:00:29 PM UTC, comment #19: 

Forgive my ignorance, but would this address the seemingly related error:

libc.a(isspace.o)*:In function `isspace'
(.text.avr-libc+0x2)*:relocation truncated to fit: R_AVR_13_PCREL against symbol `__ctype_isfalse' defined in .text.avr-libc section in c:\arduino\arduino-1.6.1\hardware\tools\avr\bin\..\lib\gcc\avr\4.8.1\..\..\..\..\avr\lib\avr6\libc.a(cty_isfalse.o)
collect2.exe*:error: ld returned 1 exit status
Error creating .elf

I've got two big projects on the atmega2560 and they are both experiencing this. The common thread is that they both use extensive use of PROGMEM to store strings.

Ryan Neve <never>
Fri 06 Mar 2015 01:59:08 PM UTC, comment #18: 

Martin Nowak's patch to replace rjmp/rcall instruction looks fine to me.
IMHO, defining RJMP/RCALL by checking _AVR_HAVE_JMP_CALL_ instead of _AVR_MEGA_ will be more meaningful.

Checked only few devices from each arch. Assemble and Link was successful.
Test case: bug33698.c with linker script bug33698.lcf (attached)
command line: avr-gcc -T bug33698.lcf bug33698.c -mmcu=atxmega128a1

(file #33259, file #33260)

Pitchumani <pitchumani>
Group Member
Wed 21 Jan 2015 08:51:20 PM UTC, comment #17: 

I made a patch to hopefully fix the issue.
This adds the XCALL/XJMP macro to libm/fplib/asmdef.h and uses that instead of explicit rcall/rjmp instructions.
The linker call still relax those instructions when possible.
Haven't yet tested the patch, but looking at the assembly output, it should work.

(file #32896)

Martin Nowak <dawg>
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>
Group administrator
Sun 05 Aug 2012 05:05:53 PM UTC, comment #13: 

More modules are:

./libm/fplib/ceil.S
./libm/fplib/exp.S
./libm/fplib/floor.S
./libm/fplib/fma.S

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


0:        rjmp        _U(__fp_nan)
        rcall        _U(__fp_splitA)
        rjmp        _U(__fp_mpack_finite)







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

Attached Files
file #33593:  rjmp-ctype.patch added by pitchumani (3KiB - application/octet-stream)
file #33469:  rcall-rjmp-lto-bug33698.patch added by dawg (40KiB - text/x-patch)
file #33259:  bug33698.c added by pitchumani (74B - application/octet-stream)
file #33260:  bug33698.lcf added by pitchumani (885B - application/octet-stream)
file #32896:  rcall-rjmp-lto-bug33698.patch added by dawg (36KiB - text/x-patch - replace rcall/rjmp with XCALL/XJMP)
file #26323:  bug_confirmation.txt added by demiurg_spb (6KiB - text/plain - confirm )

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-04-09 pitchumani StatusReady For Test Fixed
    2015-04-08 pitchumani Attached File- Added rjmp-ctype.patch, #33593
    2015-03-27 dawg Attached File- Added rcall-rjmp-lto-bug33698.patch, #33469
    2015-03-06 pitchumani Attached File- Added bug33698.lcf, #33260
        Severity3 - Normal 4 - Important
        StatusNeed Info Ready For Test
    2015-03-06 pitchumani Attached File- Added bug33698.c, #33259
    2015-01-21 dawg Attached File- Added rcall-rjmp-lto-bug33698.patch, #32896
    2012-11-16 arcanum Priority5 - Normal 9 - Immediate
    2012-08-06 demiurg_spb Attached File- Added bug_confirmation.txt, #26323
    2011-09-26 arcanum StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code