avr-libc-dev
[Top][All Lists]
Advanced

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

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


From: Björn Haase
Subject: Re: [avr-libc-dev] [bug #14855] Link Error "relocation truncated to fit: R_AVR_13_PCREL"
Date: Mon, 7 Nov 2005 17:24:50 +0100
User-agent: KMail/1.7.1

Dmitry K. wrote on Montag, 7. November 2005 08:43 
> > 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'!
>
I agree. 
The root of the problem is that the implementation of the basic 
add/compare/substract/multiply/divide operation now is not in libgcc as it 
should be, but in libm.

Concerning the issue "full C-implementation of libm": I think one might think 
about taking the function implementation from newlib's libm. However, the 
price to pay will be high. Both in code size and performance. I am presently 
working on a HC12 project where newlib's implementation is the only one 
available. It's a pain :-(. I personally would readily be willing to drop 
full IEEE compliance in order to have a lean and fast implementation.

IMO in order to at least prepare a clean solution of the issue, I'd like to 
suggest the following approach: In order to prepare the integration of 
avr-libc's libm functions into libgcc, I'd ask the original authors if they 
are willing to sign a copyright assignment for the library, so that one day 
we at least have the possibility to move the code to libgcc.

One could then add expanders for the operations provided similar to the 
divmodsi4 patterns in the machine description that actually apply only if the 
-ffast-math option is specified. Otherwise the libgcc2 function calls would 
be generated. One could then at the same time use the same method as for 
divmodsi4 for improving register efficiency by telling the compiler which 
registers are actually modified.

Presently I myself cannot promise anything right now. But I think that it 
would not hurt to prepare the copyright assignments.

Bjoern.




reply via email to

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