[Top][All Lists]

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

[avr-gcc-list] multiple -Tdata options passed to the linker for some AVR

From: Joerg Wunsch
Subject: [avr-gcc-list] multiple -Tdata options passed to the linker for some AVRs
Date: Tue, 7 Mar 2006 10:50:42 +0100
User-agent: Mutt/



Suddenly with binutils 2.16, the -Tdata option passed to the
linker ceased to work, while --section-start,.data= remained

Carlos Lamas analyzed in a thread at avrfreaks.net:


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

reply via email to

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