[avr-libc-dev] multiple -Tdata options passed to the linker for some AVRs

[Joerg Wunsch]

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. ;-)