"Weddington, Eric" <eric.wedding...@atmel.com> 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. ;-) _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
