avr-gcc-list
[Top][All Lists]
Advanced

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

Re: [avr-gcc-list] Trouble with: relocation truncated to fit: R_AVR_13_P


From: Joerg Wunsch
Subject: Re: [avr-gcc-list] Trouble with: relocation truncated to fit: R_AVR_13_PCREL
Date: Thu, 16 Jun 2011 07:58:21 +0200 (MET DST)

"Weddington, Eric" <address@hidden> wrote:

>> I've already consulted Jörg about that, and that the hackish
>> "overwrite" of stuff from libgcc by avr-libc does not always work
>> as intended.

> Do we know why that is the case, why it's not working for certain
> cases? Because it does work in other cases.

It works incidentally.  I think, in the past we've got the entire
avr-libc within a single section, so chances were better everything
has been linked together local enough to meet the RJMP condition.
Now, with the per-function sections, chances are better they get far
apart in the resulting binary.

We should turn them all into long jumps/calls, and have the linker
relaxations do their job later on.

>> It's obvious that the desired solution was to have that code
>> integrated into libgcc instead of in avr-libc (which is not the
>> case for reasons we all know).

Your proposed solution looks easy to implement, though I'd prefer if
we could instead move *all* of avr-libc's functions that duplicate
libgcc functionality out into libgcc.  Obviously, that requires that
all relevant contributors agree to re-license their code under GPL,
and to sign the dreaded (and IMHO pretty useless) FSF copyright
assignment.

Only failing that, I'd like to see yet another hack …
-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)



reply via email to

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