AW: [avr-gcc-list] multiple -Tdata options passed to the linker forsome AVRs

[Haase Bjoern (PT-BEU/EMT) *]

>> 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?

My idea for a clean solution was, to solve the issue by writing one
single "database"-c file that is used as code generator for all of

Avr-libc
Gcc
Binutils

. The file would define one "component struct" including the component's
name (e.g. atmega128) entries for the instruction set (e.g. "has_hw_mpy"
"has_movw") and the memory limits for eeprom, ram and flash.
The file moreover would include one initialized const array of such
structs for all of the devices.

The code of this "database" program would extract the required data and
generate device specific header files that are needed for all of the
different projects. I'd suggest to make avr-libc the main host project
of this file so that it could be easily changed. Periodically, one would
commit updates of it to the other projects.?

My hope is, that this way one would be having only some initial work,
but would have less maintenance problems.?

Bjoern.