Re: [avr-gcc-list] A fork in the road [Was: Linker script patch with __flashN size]

[Erik Christiansen]

On 20.12.12 21:25, Georg-Johann Lay wrote:
> Erik Christiansen schrieb:
> >Because __flashN have fixed page addresses in the middle of the AVR
> >flash memory map, the old monolithic .text output section is now best
> >split into .lowtext and .hightext, as in the new script. That allows
> 
> My main objection is that this will raise myriads of support requests
> because applications break.  Users will upgrade to the new version
> and *nothing* will work because .text is missing -- no matter whether
> they use __flash or not.  I don't think this is a good idea.

Using the mechanism outlined later in this post, binutils will only
employ the new linker script architecture for avr6 and above, so the
lower avr architectures will be unaffected by the new script. And even
for avr6, tweaking an avr-objcopy invocation in a makefile target will
only be required when upgrading the toolchain - something that no
professional does in the middle of a project. The scenarios for upgrade
shock are few, in practice. Nothing should break, because a new project
will use contemporary avr-objcopy commands.

We will provide makefile examples for the convenience of users of avr6.
Some of the examples may use avr-objcopy -S -Rxxx, which removes
dependence on magic output section names.

...

> >The new architecture also greatly simplifies correct location of the
> >code in all the various use cases. In addition, it permits the use of
> >ld's automatic overlap detection, and facilitates manual overflow
> >detection, using assertions. The many failures Johann reports in his
> >script attempt are largely due to using a venerable script architecture
> >which has been obsoleted by the new AVR memory spaces supported in
> >avr-gcc.
> 
> Well, the hacks we need are to work around shortcomings of the linker
> script language as mentioned in
> 
> http://sourceware.org/ml/binutils/2012-12/msg00151.html

The most salient imagined "shortcomings of the linker script language"
were adressed in:

http://sourceware.org/ml/binutils/2012-12/msg00152.html

so no hacks are required when a capable linker script is used.

> >As running a test case, using Johann's test harness shows, a quick
> >avr-objdump -h now gives us an instant clear view of where everything
> >went, and how much overflow or overlap margin there is, well before
> >trouble strikes, and we cop an error message.
> 
> A new flash.sx is attached.  It also knows DATA now.  Thus we can set
> the following defines to cook up a test case:
> 
> Code in flash: TEXT, LOWTEXT, STUBS, BOOT ("ax" orphan)
> Data in flash: CTORS, P0, P1, P2, P3, PX
> Data in RAM  : DATA

Great. I'll look at switching over.

> The new file also sets up __need_.progmemN.data symbols as needed by
> the new script.  It mimics what avr-gcc will do with the patch
> applied.

That looks like a completely unnecessary avr-gcc hack, justified only by
deficiencies in your script attempt. It is not advisable to hack
avr-gcc, just to get a poor linker script to work, most especially when a
publicly tested linker script shows that the hack is unnecessary.

If we abandon binutils norms, and instead hack linking manipulation into
the compiler, then the avr port will in time become unmaintainable, I
suggest.

> >My vote is to favour continued development of the tested successful
> >script candidate over the repeated failures of the other. Its current
> >effectiveness and resilience bodes well for unanticipated future
> >enhancements. Any tweaking requests can be knocked over then. (There
> >does not seem to be any hurry for any of this.)
> 
> Remaining trouble:
> 
> Binutils generate all scripts from one template, avr.sc.

That is an incomplete analysis of the situation. Binutils is in fact
ideally set up to handle our new linker script architecture, using a
second avr.sc. Currently, binutils-2.23/ld/Makefile.in provides a
separate make target for each avr architecture, each individually
specifying which xxx.sc to employ. Thus, it is effortless to use another
script template for the more advanced avr architectures.

If template proliferation proves unpopular upstream, then we can
alternatively customise in binutils-2.23/ld/emulparams/avr6.sh instead.
But that would involve more effort.

> I found no way to get a double quote (") into the generated ld
> scripts.  " will be killed, \" will yield a \" and using single quotes
> will print single quotes without any effect on "

Can you demonstrate the problem? Since quotes _are_ currently being
handled in the generation of avr linker scripts, is it the way you're
doing it that is the problem?

I.e. binutils-2.23/ld/scripttempl/avr.sc already contains:

OUTPUT_FORMAT("${OUTPUT_FORMAT}","${OUTPUT_FORMAT}","${OUTPUT_FORMAT}")

which is extremely lightly munged to produce:

OUTPUT_FORMAT("elf32-avr","elf32-avr","elf32-avr")

in avr6.x. I.e., no visible problems with quotes at at all.

And looking at binutils-2.23/ld/genscripts.sh, to check the mechanism,
we find that the sed munging is trivial, and does not interfere with
quotes in any observable way.

Also, the line:

. ${CUSTOMIZER_SCRIPT}

invokes binutils-2.23/ld/emulparams/avr6.sh for the avr. That not only
doesn't do anything to clobber quotes, but in fact uses them itself.

But don't worry about it. If any tweaking of binutils processing of
avr.sc were in fact needed, it all looks simple enough to be amenable to
our ends.

In short, there does not appear to be sufficient "Remaining trouble" to
be any form of obstacle to a capable linker script. (Given a couple of
tweaks in binutils scripting for the avr target.)

Erik

-- 
The ultimate barrier is one's viewpoint.
      - Terry Pratchett, "The Dark Side of the Sun"