[avr-gcc-list] AVR Dual-Scripting patched into binutils now. [Was: A fork in the road]

[Erik Christiansen]

On 19.12.12 17:53, Weddington, Eric wrote:
> Hi Erik,
> 
> So far, I like how you're describing it below.
> 
> Did I miss the actual linker script that you're proposing? Do you have a 
> patch?
> 
> Eric

As intimated upthread, here are three simple patches which now
incorporate the avr6 script into binutils as a second script template,
and add tweaks to activate the binutils capacity for multiple templates.
This now autogenerates the full set of avr6 linker scripts in binutils,
from the additional template.

As a consequence, users of other avr architectures will continue to use
the old linker script, and will remain blissfully unaffected by the new
features in the more advanced script.

If we want the features for any additional architectures, then the new
linker script can be switched in where and when needed, with
customisation, if needed.

Clearly, the toolchain is not limited to one linker script template, as
had been feared.

I have done regression testing (repeating the original test set), but
some independent testing at some stage would do no harm.

The most recent requirements (feature) list I have stumbled across is on
another list. All requirements in that list are satisfied:

On: Mon, 07 Jan 2013 20:59:03 +0100, Georg-Johann Lay wrote:
(In http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00346.html )

> The problems to be solved are:

> 1) .progmem<N>.data must be located in [0x<N>0000, 0x<N>ffff].

> 2) If there is too much data in .progmem<N>.data the linker should
   complain.

> 3) Moving the location counter to 0x<N>0000 is only needed if
>    .progmem<N> is non-empty.

The test results published upthread show that the new linker script
satisfies these requirements.

> 4) We must be careful not to move to pointer backwards.

Ld will bitch if that were to happen. It doesn't.

> 5) User-level build-scripts and Makefiles should be the same if
>    the user does not use the new features like __flash<N>.
>    Even if __flash<N> is used, it's appreciated if everything
>    works out of the box and without changing calls of objcopy,
>    for example.

The new dual linker script template facility avoids any such issues for
users of architectures which do not employ __flash<N>.

Users of architectures using __flash<N> will find the improvement easy
to enjoy.

> 6) If .text extends to, say, 0x20010, it's still fine if .progmem2.data
>    starts at 0x20011.  There is no need to throw an error because text
>    overlaps 0x20000...0x2ffff.

The test results published upthread show that the new linker script
satisfies this requirement.

In a follow-up on that list, I wrote:

> Let's see what Eric Weddington says after he's tried out the new linker
> script, possibly with additional test cases. The new script is more
> powerful and flexible than the old. It should be fairly easy to add the
> afterthoughts which are sure to crop up now that the basics are done.

> If he's happy, I'll implement the binutils tweak to employ one script
> template for lower avr architectures, and another for avr6. Fortunately,
> Makefile.in is already set up to handle that, so there's not a lot of
> work for me to do.

Well, that's delivered in this post, for further testing and comment.
Once we have dealt with __memx and anything else immediately useful,
I'll submit it to binutils.

Erik

-- 
"What is wanted is not the will to believe, but the will to find out,
which is the exact opposite."
                           - Bertrand Russell, _Sceptical_Essays_, 1928

avr6.sc.patch
Description: Text Data

avr6.sh.patch
Description: Text Data

Makefile.am.patch
Description: Text Data