Re: [avr-gcc-list] multiple -Tdata options passed to the linker for some AVRs

[Erik Christiansen]

On Tue, Mar 07, 2006 at 10:50:42AM +0100, Joerg Wunsch wrote:
> 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.

The maintenance overhead could be eased by INCLUDE-ing common linker
script stuff couldn't it? Conditional assignment of linker variables
would also help with writing more generic scripts. With these aids,
would there be a need for more than the existing per-architecture script
collection? Admittedly, there would be some disruption during
transition.

> Are there any other ideas how to circumvent that problem?

If the linker script were to link .data input sections into a safe new
output section:

.avr_data {
   *(.data)
   ...         /* etc. */
}

and 

MEMORY
{
  ...
  avr_data   (rw!x) : ORIGIN = 0x800100, LENGTH = 4K
  ...
}

then the problem would be circumvented, I expect, if the "good" -T
references this output section. There would then be nothing in the now
unused .data section. (And avr-gcc will never know. :-)

> Btw., does anyone know why there are five linker scripts per
> device/architecture?  (.x, .xbn, .xn, .xr, .xu)

Only what is stated at the head of each one. (I'm afraid I've just
borrowed one, and then rolled my own from there.)

Erik