See: http://sourceware.org/bugzilla/show_bug.cgi?id=1272
Suddenly with binutils 2.16, the -Tdata option passed to the linker ceased to work, while --section-start,.data= remained functional. Carlos Lamas analyzed in a thread at avrfreaks.net: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=208997 that this is due to the way the compiler overrides the generic RAM location supplied by the linker scripts for all AVRs with extended IO register space. In fact, adding -v to the linker command line reveals the problem: /usr/local/lib/gcc/avr/3.4.4/../../../../avr/bin/ld -m avr5 -Tdata 0x800100 -o foo.elf /usr/local/lib/gcc/avr/3.4.4/../../../../avr/lib/avr5/crtm128.o -L/usr/local/lib/gcc/avr/3.4.4/avr5 -L/usr/local/lib/gcc/avr/3.4.4 -L/usr/local/lib/gcc/avr/3.4.4/../../../../avr/lib/avr5 -L/usr/local/lib/gcc/avr/3.4.4/../../../../avr/lib -Tdata=0x8011000 /var/tmp//ccG96yi3.o -lgcc -lc -lgcc There are two -Tdata options passed down to the linker. Obviously, the order of evaluation has been changed between binutils 2.15 and 2.16, but we can hardly blame them for this. This is a genuine problem of our current setup. Carlos claims only reverting to per-device linker scripts would cure that. While for sure, they have some merit (e. g. the linker would be able to flag overflown sections accurately except for devices that can drive external RAM), I'm somewhat reluctant to make that step due to the increasing maintenance overhead. Are there any other ideas how to circumvent that problem? Btw., does anyone know why there are five linker scripts per device/architecture? (.x, .xbn, .xn, .xr, .xu) -- 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 http://lists.nongnu.org/mailman/listinfo/avr-gcc-list