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

[Erik Christiansen]

On 19.10.13 19:48, Georg-Johann Lay wrote:
> Dhakshinamoorthy, Soundararajan schrieb:
> >I am trying to update the linker scripts, with the start address of
> >boot section, which is different for each device (or atleast i don't
> >seem to find a way to compute it based on the information available
> >in binutils )
> 
> 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.)

> Maybe you can have a look at how the tools handle different RAM start: The
> compiler just calls the linker with Tdata to provide the information.  This
> you could add a new column to ./gcc/config/avr/avr-mcus.def and use that
> information appropriately.

One scary aspect of that approach is this comment in that file:

/* List of all known AVR MCU types - if updated, it has to be kept
   in sync in several places (FIXME: is there a better way?):
    - here;
    - gas/config/tc-avr.c;
    - avr-libc.
...
*/

If adding parameter columns, the AVR_MCU macro would also need to be
extended, at a minimum. And the extra coding work seems unnecessary.
The "FIXME", above, also suggests that amplifying the syncing task isn't
the best way forward. I wonder if something along the following lines is
sufficiently more maintainable to be worth pursuing?

1) Don't add device-specific addressing guff to avr-gcc, avr-as, or
   avr-libc.

2) Instead, just transparently emit the received -mcu parameter, as e.g.
   "/defs/atmega328p" on the avr-ld command line.
   (Now _that's_ less work, and it's only ever done once in each of
   avr-gcc and avr-as.)

3) Drop into a "defs" directory, a very short definition file for each
   AVR device, containing legal linker script lines, such as:

   __boot_start = 0x12345 ;

   Depending on where defs/ is placed relative to /usr/local/avr/avr/lib/
   a "-L path" might be needed at point 2. (Again, set and forget.)

4) The linker automatically uses the defs/xxx file on the command line to
   augment the main linker script, (See man ld)

   For the example in 3) above to solve Soundararajan's issue, the boot
   section definition in the linker script should be:

  .boot __boot_start :
  {
    *(.boot_vectors)
    *(.boot)
  } > text

5) Now syncing is automatic, since avr-gcc, avr-as, and avr-libc rely on
   the linker to do its job without micromanagement.

   Adding a new device then only involves editing a text file e.g.
   defs/atmega12345 and plugging in any desired address definitions in
   linker script syntax.

The role of the architecture based emulations remains untouched.
The device-specific augmentation file simply tweaks the architecture
based linker script to the extent that ld supports.

If it were desired to add the boot section only sometimes, that could be
done too, given decision making by avr-gcc.

If nothing else, such notions might stimulate further thought on how
best to make the AVR toolchain easier to maintain.

Erik

-- 
The 20th Century was about dozens of markets of millions of consumers.
The 21st Century is about millions of markets of dozens of consumers
                                                     - Joe Kraus, dotcom pioneer