[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] [bug #14855] Link Error "relocation truncated to fit:
Re: [avr-libc-dev] [bug #14855] Link Error "relocation truncated to fit: R_AVR_13_PCREL"
Mon, 7 Nov 2005 17:43:08 +1000
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:
volatile double x = 0;
int main ()
return 0/x == 0/x;
Script to run:
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
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
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'!