Re: [avr-libc-dev] [bug #14855] Link Error "relocation truncated to fit: R_AVR_13_PCREL"

[Dmitry K.]

Sorry, I misprint CC-address.

On Monday 07 November 2005 16:04, Joerg Wunsch wrote:
> Follow-up Comment #6, bug #14855 (project avr-libc):
> > > 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.

Now the opportunity of choose works.
Look an example:

foo.c:
~~~~~
   volatile double x = 0;
   int main ()
   {
       return 0/x == 0/x;
   }

Script to run:
~~~~~~~~~~~~~
   #! /bin/sh
   set -e

   avr-gcc -Os -o foo-gcc.elf foo.c
   simulavr-auto -d foo-gcc.elf

   avr-gcc -Os -o foo-m.elf foo.c -lm
   simulavr-auto -d foo-m.elf

   avr-size *.elf

Result:
~~~~~~
   0
   1
      text    data     bss     dec     hex filename
      2012       8       4    2024     7e8 foo-gcc.elf
       562       0       4     566     236 foo-m.elf

First program (foo-gcc.elf) is linked with libgcc's
modules. It produces 0, as NaN is not equal to NaN.

Second program (foo-m.elf) is linked with libm's modules.
It produces 1:  NaN/Inf/Subnormals are not fully released
in Avr-libc/libm.  But compare size!


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

No!
The error is to mix the libraries. Is inadmissible to replace
a part of library another if the author did not project such
replacement initially. 'libm' uses some assumptions of use
of registers to which does not follow 'libgcc'.  Remember,
for example, about jump through stack in 'libm'!

Dmitry.