[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-libc-dev] [bug #33698] Explicit use of RJMP/RCALL can cause "reloca

From: Georg-Johann Lay
Subject: [avr-libc-dev] [bug #33698] Explicit use of RJMP/RCALL can cause "relocation truncated to fit: R_AVR_13_PCREL" linker error
Date: Sun, 19 Feb 2012 10:06:05 +0000
User-agent: Opera/9.80 (Windows NT 5.0; U; de) Presto/2.6.30 Version/10.63

Follow-up Comment #11, bug #33698 (project avr-libc):

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.


Reply to this item at:


  Nachricht geschickt von/durch Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]