Re: [avr-gcc-list] Device specific linker scripts

[Erik Christiansen]

On 20.10.13 21:36, Georg-Johann Lay wrote:
> Erik Christiansen schrieb:
> >On 19.10.13 19:48, Georg-Johann Lay wrote:
> >>If such linker scripts shall become the default linker scripts then you need
> >>200+ emulations to support the 200+ devices.
> >
> >One way to follow Johann's good advice might be to just use:
> >
> >  .boot :
> >  {
> >    *(.boot_vectors)
> >    *(.boot)
> >  } > text
> >
> >and have gcc set --section-start=.boot=0x12345
> >That should suffice for now.
> >
> >And yes, 4 x 205 = 820 full linker scripts is about what would happen if
> >we were, for example, to proliferate what I sometimes do for the
> >Atmega64:
> >
> >MEMORY
> >{
> >  text   (rx)   : ORIGIN = 0, LENGTH = 62K
> >  boot   (rx)   : ORIGIN = 62K, LENGTH = 2K
> >  data   (rw!x) : ORIGIN = 0x800100, LENGTH = 4K
> >  eeprom (rw!x) : ORIGIN = 0x810000, LENGTH = 2K
> >}
> >
> >SECTIONS
> >{
> >...
> >  }  > text
> >
> >  .boot :
> >  {
> >    *(.boot_vectors)
> >    *(.boot)
> >  } > boot
> >
> >  .data    : AT (ADDR (.text) + SIZEOF (.text))
> >  {
> >
> >That satisfied my strong preference for documenting the memory layout in
> >the linker script. (Having all that information in one place can save
> >time when coming back to an old project.)
> 
> 
> Wouldn't this cause problems if no bootloader is present and .text overlaps
> empty bootloader section?

Well, avr-ld would protest if the text region limit of 62k were exceeded,
even if the boot section were removed. I.e. The primary error would be
memory region overflow, even if a section overlap didn't follow. (Perhaps
that's what you meant, I guess.)

The custom linker script (negative) example explicitly amplified your
warning of emulation proliferation, using a method which is fine for
one-off. Your description of the generalisation issue is quite accurate.
Soundararajan is doubtless already oriented toward the preceding positive
example, or something similar.

The rest of my post looked at a possible way to avoid having to hack
avr-gcc to embed linker-related stuff, as is needed in the positive
example, since such indirection unnecessarily amplifies the amount of
work to be done for each new mcu.

...

> Still avr-gcc has to be extended to accept -mmcu=atmega12345, so that file
> has to be touched anyway.

Well, only if avr-gcc internally requires extension of compiler
functionality for the new mcu. The goal of the proposal is to avoid the
inefficiency of changing avr-gcc when only link-time changes are
necessary. I.e. it is sub-optimal to have to hack avr-gcc to emit
--section-start=... for every mcu, old and new, when it can be just
dropped into a text file, for avr-ld to use directly.

Furthermore, any future linker address customisations for an mcu are
just dropped into the same mcu def file, without resort to _any_ coding,
macro extension, or fiddling with avr-gcc to drive avr-ld.

There seems to be enough work for the available developers for any
potential effort reduction to be worth a look.

And thank you, Johann, for taking the trouble to discuss - it helps to
keep the list from being too moribund.

Erik

-- 
Tecoma's struggle reported on BBC: http://www.bbc.co.uk/news/business-24364204
Tecoma's Macca's-striking flash mob: " 
http://www.youtube.com/watch?v=H7-0T1vbnWE
Stop fat food joint opposite Tecoma preschool: www.change.org
Taking democracy (98,000 signatures) from Australia to Chicago:
http://www.abc.net.au/news/2013-09-17/tecoma-residents-take-fight-against-mcdonalds-to-chicago/4963866