Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » AVR-GCC
  • » [avr-libc-dev] [bug #14855] Link Error "relocation truncated to fit: R_AVR_13_PCREL" [RSS Feed]

#1 Nov. 7, 2005 07:39:34

Dmitry K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

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


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.



_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.orghttp://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Offline

#2 Nov. 7, 2005 14:28:18

Joerg W.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

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




As Dmitry K. wrote:

(About two different implementations for __addsf33x et al.)

> Now the opportunity of choose works.

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

Yet, the libm version is inherently broken. GCC claims
support for IEEE features, so we cannot ignore them.

I a user wants to choose an inferior implementation for floating-point
routines that are supposed to be in libgcc.a, we should offer them a
separate library that can be explicitly given on the command-line (as
libsimplefp.a, not via -l) so it will take precedence over libgcc.a.
It should not be bundled with libm.a though.

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

> No!
> The error is to mix the libraries.

The error is to replace library functions that are in the domain of
libgcc.a in a different library. If a full replacements exist, they
need to be supplied to the GCC team for inclusion into libgcc.a.

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

Sigh. This is another bug then. If the functions have identical
names, they should have identical calling conventions.

We seriously need a maintainer for libm.a. As the state is now, I
tend to drop support for fplib completely, and release it on a `use at
your own risk' base. I'm unable to maintain it myself, and nobody
else appears to be willing or able to maintain it. We've got half a
dozen of bug reports open for it (some of them for more than 3 years),
and nobody in sight to really fix anything there.

It would be better to supply a large but accurate libm.a that is based
on C code and can be maintained easily by any team member, rather than
the cruel hack we're suffering from right now. Even though it's
pretty small in code size, it's got so many problems that turn out to
be inherent due to the way it has been written, I feel it's no longer
justifiable to `sell' it to our users that way. It could perhaps be
built as a standalone hack that can be used by those who could live
with the bugs given the code size saving, but I'd rather like to see a
default libm.a that follows the same quality of implementation
standards as both, GCC as well as the remainder of avr-libc.

I might sound a bit pissed off here, and yes, I actually am. I've
been trying to fix bugs in that library off and on myself, and I'm now
simply sick of that. With all its internal cruft, it turned out to be
unmaintainable.

I'm not going to drop the current fplib for 1.4.0 (as it would defer
1.4.0 even more than it already is behind schedule), but unless
someone really steps forward and wants to fix all those bugs, and
continue maintaining fplib (that is, actively maintaining it,
including the require CVS skills, and taking over responsibility for
handling all future bug reports as well), I'll see to rewrite all the
math functions in C after 1.4.0 has been shipped, and eventually
replace the existing library. In that case, 1.6.0 would then ship
with a new libm.a (probably joined into libc.a), and ship fplib as a
separate add-on item only for those who really want to use it,
explicitly marking it as being unmaintained. I'll close all open bug
reports for that library than as "won't fix", and not accept new bug
reports.

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTLhttp://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)



_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.orghttp://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Offline

  • Root
  • » AVR-GCC
  • » [avr-libc-dev] [bug #14855] Link Error "relocation truncated to fit: R_AVR_13_PCREL" [RSS Feed]

Board footer

Moderator control

Enjoy the 20th of November
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support