bugAVR C Runtime Library - Bugs: bug #14855, Link Error "relocation...


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

bug #14855: Link Error "relocation truncated to fit: R_AVR_13_PCREL"

Submitter:  None
Submitted:  Tue 25 Oct 2005 09:50:19 AM UTC
Category:  Library Severity:  3 - Normal
Priority:  7 - High Item Group:  libm code
Status:  Fixed Percent Complete:  0%
Assigned to:  None Originator Email:  * -email is unavailable-
Open/Closed:  Closed Release:  * None
Fixed Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Thu 20 Mar 2008 05:42:28 AM UTC, comment #8: 

This one has really been fixed by the new libm code.

Joerg Wunsch <joerg_wunsch>
Project Administrator
Fri 01 Sep 2006 06:29:35 PM UTC, comment #7: 

Is this still a valid bug?

Eric Weddington <arcanum>
Project Administrator
Mon 07 Nov 2005 06:03:59 AM UTC, comment #6: 

> > This rather looks like a libgcc bug to me then.  libgcc should not
> > supply anything that is supplied by avr-libc.

> Now there is an opportunity to choose, what base float arithmetic
> functions to use: high-quality from 'libgcc' or compact and fast
> from 'libm'.

Well, no, that can't be the way.  libgcc is always linked, and any
calls into it need to be far calls (where applicable).  If we want to
supply two different libm.a options, then we should offer that as a
user-selectable option, but still keep it outside of libgcc.a.

I tend to classify these routines as `broken' if they don't yield the
same results as libgcc.a ones.  If we supply replacements for libgcc
functions (because we could get the job quicker done than the generic
code), they need to behave exactly the same.  Even then, I think these
functions should rather be imported into libgcc.a then instead.

So I think that bug should be resolved by using XJMP instead of

Other opinions?

Joerg Wunsch <joerg_wunsch>
Project Administrator
Sun 06 Nov 2005 09:19:30 PM UTC, comment #5: 

This rather looks like a libgcc bug to me then.  libgcc should
not supply anything that is supplied by avr-libc.

Joerg Wunsch <joerg_wunsch>
Project Administrator
Fri 04 Nov 2005 02:45:58 AM UTC, comment #4: 

The reason consists that the 'avr-g++' inserts libraries 'gcc'
and 'm' in addition before to user ones.  With 'avr-gcc' all works:
it inserts default libraries (gcc, c and gcc again) after
user ones.

Resulted below the program illustrates a mistake:

  avr-g++ -mmcu=atmega168 -o foo3.elf foo3.cpp -lm
     ==> many errors: relocation truncated to fit
  It is possible to look library sequence with '-v' switch:
     avr-ld ... /tmp/ccHZLoOn.o -lgcc -lm -lgcc -lc -lgcc

  Here functions from Avr-libc/libm use not the the own base
  arithmetic functions, and take them from library which has been
  picked up earlier.

  With 'C' compiler all works:
  avr-gcc -mmcu=atmega168 -o foo3.elf foo3.cpp -lm
    ==> OK
  Looking by '-v':
     avr-ld ... /tmp/ccCdQL2u.o -lm -lgcc -lc -lgcc

  'C' compiler with incorrect library sequence:
  avr-gcc -v -mmcu=atmega168 -o foo3.elf foo3.cpp -lgcc -lm
     ==> result is like (1), the same errors.

It is possible to use the 'avr-g++', having forbidden implicit
connection of libraries:
  avr-g++ -nodefaultlibs -mmcu=atmega168 -o foo3.elf foo3.cpp -lm -lgcc
     ==> OK

Example program:
  #include <math.h>

  volatile double val;

  int main ()
      double x, y;
      int i;

      x = (val * 1.2 + 1.3) / 1.4;
      if (x < 1.5 && x > -1.6 && x != 0.17)
          x -= 1.8;
      x = -x;

      x = acos(x);
      x = asin(x);
      x = atan(x);
      x = atan2(x, 0.19);
      x = ceil(x);
      x = cos(x);
      x = cosh(x);
      x = exp(x);
      x = fabs(x);
      x = floor(x);
      x = fmod(x, 0.20);
      x = frexp(x, &i);
      x = ldexp(x, 3);
      x = log(x);
      x = log10(x);
      x = modf(x, &y);
      x = pow(x, 0.21);
      x = sin(x);
      x = sinh(x);
      x = sqrt(x);
      x = tan(x);
      x = tanh(x);

      return (int)x;

(I have use avr-g** 4.0.2, binutils 2.16.1 and Avr-libc 1.2.5).

And about of Avr-libc.
Usage of short instructions (rcall/rjmp) is safe due to summary size
of Avr-libc/limb functions is less then 4K bytes.  It is no sence
(for common linking, where '-lm' is after all user's), the section is
'.text.fplib' or simply '.text'.


Sat 29 Oct 2005 06:11:50 AM UTC, comment #3: 

Hi Joerg,

it is my understanding that the fplib does already use local sections. Look e.g. at ceil.S. It uses

define TEXT_SEG(subs, func) .section .text.##subs, "ax", @progbits ; func

          TEXT_SEG(fplib, ceil)


Thu 27 Oct 2005 08:57:35 PM UTC, comment #2: 

My first idea was to force all fplib functions
into a single .text.fplib subsection, so the linker
will link them closely together.

Björn, do you think that would work?

Joerg Wunsch <joerg_wunsch>
Project Administrator
Thu 27 Oct 2005 07:35:07 PM UTC, comment #1: 

The reason for this issue is (I am almost certain) that libm uses rcall and rjmp for internal function calls. Usually the distance between the different functions is small enough so that this does not cause problems. In your case, however, it seems that your code causes the distance to become too large.

I'd like to suggest the following solution:

1.) Replace all of the rjmp and rcall instructions in the assembler code by FARJMP / FARCALL macros (to be defined) that expand to rjmp and rcall for the avr2 and avr4 families and jmp/call otherwise.

2.) Use linker relaxation (will hopefully be available in the binutils cvs next week) for replacing jmp/call by the shorter variants where possible.



Tue 25 Oct 2005 09:50:19 AM UTC, original submission:  

I'm getting a linking error ( below ) using g++ 3.4.3 with an ATMega168.

I can make the source compile or not compile by commenting out a line equivalent to 'f+=10.0' where f is a float.

The linker version is 2.15.
switching back to gcc ( from g++ ) shrinks the code dramatically ( much more than the usual g++/gcc difference ) and the problem goes away.  Don't know if it will reappear as I reach the memory limits.

Thread here:


Linking: controller.elf
avr-g++ -mmcu=atmega168 -I. -gstabs -DF_CPU=11059200UL -DUART_RX_BUFFER_SIZE=128 -DUART_TX_BUFFER_SIZE=16 -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wa,-adhlns=controller.o -I../hal -I/home/bu/include/avr -I/home/bu/include/avr/procyon -MD -MP -MF work/.dep/controller.elf.d controller.o ../hal/serial.o ../hal/uart/uart.o /home/bu/src/avr/procyon/cmdline.o /home/bu/src/avr/procyon/encoder.o --output controller.elf -Wl,-Map=controller.map,--cref -lm
/usr/lib/gcc/avr/3.4.3/../../../../avr/lib/avr5/libm.a(exp.o)(.text.fplib+0x36): In function `exp':
../../../../libm/fplib/exp.S:87: relocation truncated to fit: R_AVR_13_PCREL no symbol
/usr/lib/gcc/avr/3.4.3/../../../../avr/lib/avr5/libm.a(log.o)(.text.fplib+0x3e): In function `log':
../../../../libm/fplib/log.S:111: relocation truncated to fit: R_AVR_13_PCREL no symbol
make: *** [controller.elf] Error 1



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

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by joerg_wunsch (Updated the item)




    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-03-20 joerg_wunsch Open/ClosedOpen Closed
    2008-03-20 joerg_wunsch StatusNone Fixed
    2007-01-08 joerg_wunsch Item GroupNone libm code
    2005-10-27 joerg_wunsch Priority5 - Normal 7 - High
    2005-10-25 None Carbon-Copy- Added dan_sandberg --AT-- yahoo --DOT-- com

    Back to the top

    Powered by Savane 3.9