[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
Re: [avr-gcc-list] Trouble with: relocation truncated to fit: R_AVR_13_PCREL
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
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. ;-)