[Patch,avr] Add predicate symbols for the linker script to bump sections containing addr-space data

[Erik Christiansen]

Apologies for this post linking to the thread only by subject - the
maillist archive does not appear to contain references which would allow
this post to link solidly. (I've only subscribed a few minutes ago.)

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 )

> This is a tentative patch that adds symbols that can be used as
> predicates in the linker script.

I'm sorry, but the patch is entirely unnecessary, since a linker script
exists which achieves all the essential goals of this patch, without
attempting to bury linking functionality in the compiler. [4]

It is, IME, not a good idea to embed linker behaviour in the compiler.
Doing so would lead to brittleness in avr-gcc, as future options become
constrained by poor past decisions. Maintainability of avr-gcc also
suffers.

It is no accident that PR14406 is against binutils. That is where section
location needs to be enhanced. Sorry, but that is not compiler
functionality.

> Background is binutils PR14406: Data in address space __flash1 must be located
> in such a way that the high byte (hh8) of the address is 0x1.  This is needed
> because avr-gcc sets RAMPZ to 0x1 before reading data from __flash1.

> The input section for __flash1 is .progmem1.data

> Similar for other __flash<N>, n = 2..5

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

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

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

> 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 very problem is that the linker script language is too limited.  Neither
> does it support memory holes, nor can a section float around others, and not
> even detecting if a section does not contain any data works as promised by
> binutils, cf. [1].

I'm sorry, but that is only mistaken belief. The language is largely
sufficient for competent scripters - to the extent that the linker
script in [1a] (follow-up to [1]) does support memory holes, and does
float sections around others, as well as "detecting if a section does
not contain any data". (It opens up .lowtext and .hightext like a
clamshell, to insert any populated __flash<N> sections, then closes the
clamshell about the whole, to avoid wasting memory.)

If there is any doubt, then please run the testcases, also included in
[1a]. (Or at least read the included "avr-objdump -h" outputs which show
the results.) They confirm automatic opening of holes, for insertion of
the __flash<N> sections, with automatic butting up, to conserve memory.
These have been published on binutils and avr-gcc maillists since last
year, without technical challenge. Please try all the test cases. (They
use Georg-Johann's nifty test macros.)

> The patch addresses the latter problem: It defines symbols that can be used
> like predicates by the linker script like so, cf. [2]:

>   .text   :
>   {
>     ...

>     . = MAX (DEFINED(__need_.progmem1.data) ? 1 << 16 : 0, ABSOLUTE(.)) ;
>     __progmem1_start = . ;
>     *(.progmem1)
>     *(.progmem1.*)
>     __progmem1_end = . ;

>     ...
>   } > text

A competent linker script does not need crutches embedded in the
compiler. The script in [1a] allows ld to do the linking and location
unaided by hacks in avr-gcc. (If anything needs tweaking, please show a
testcase.)

> There was some discussion in [3] about how PR14406 could be approached and
> there were basically two proposals:

> - One from Erik that does not solve
> 3),

Sorry, that is false. The published test results demonstrate that the
competent linker script does move the location counter to 0x<N>0000 only
if __flash<N> is non-empty. Please _try_ the relevant published
testcases. E.g. the last testcase in [4] shows that ".hightext) snugs down
[to .lowtext] if there are no __flashN" i.e. empty __flash<N> are fully
handled.

> 6)

Ahem, that is also false. The published test results also demonstrate
that the competent linker script does not "throw an error because text
overlaps 0x20000...0x2fff". The last testcase in [4] shows text (in
.hightext) running from 0000010c to 0002016e, without any hassles.

> or 5)

But I am forced to agree that those not using the avr6 architecture
should not be inconvenienced at all. Those who decide to do so should
only encounter a small upgrade learning curve, and it should make
logical sense, so that the cost/performance gains are obvious and very
attractive.

It is only recently that I have outlined, on avr-gcc ML, how easy it
is to leave most users happily oblivious to the enhancements to avr6.
I.e. users of lower cpu architectures would not be exposed to the
enhanced linker script, so cannot be affected by it. ;-)

> i.e. requires a change in the user Makefiles like  -j .hightext
> instead of  -j .text  etc. .text is after .progmem<N>

Well, embedded systems programmers usually have to rewrite or at least
tweak the makefile for each new project. A trivial variation in
avr-objcopy parameters is less than a non-issue in that context, I
submit. It is not as if we're adding a new command to run. We will
supply makefile examples for the user's convenience.

> - One from me with the predicate-like-symbols kludge that needs a
>   GCC change and has less informative error messages than Erik's
>   approach in the case anything overflows.
>   .text is before .progmem<N>

It's clear by now that IME a completely unnecessary linker-behaviour
kludge should not be inflicted on avr-gcc.

Given that the self-sufficient linker script also has more informative
error messages, then there seems to be no reason to proceed with the
kludge.

> Maybe everything can be solved much easier and I am lacking the respective
> binutils knowledge...

Johann, it has taken many years to accumulate the skills and confidence
to whack on the head any linker script challenges I've had to solve so
far. I remember what it was like when it seemed that the language was
"limited", but now I realise that it was only experience which was lacking.

It is easier than fixing gcc bugs, but that does not mean that it can be
learned overnight. The documentation is quite a good reference once
you're familiar with ld, but I found that great persistence and much
experiential learning was required at the bottom of the learning curve.

> Thoughts?

Cooperation has great advantages. Targeting our efforts in the areas
where we have strongest skills will maximise our effectiveness.

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.

In parallel, we can discuss what's needed for __memx. It would be good
to have thoughts from userland, but we can start without. (In the
absence of prior thoughts, I'll post on avr-gcc re that in the next day
or two.)

Erik


> [1]  http://sourceware.org/ml/binutils/2012-12/msg00151.html
  [1a] http://sourceware.org/ml/binutils/2012-12/msg00152.html
> [2]  http://lists.gnu.org/archive/html/avr-gcc-list/2012-12/msg00046.html
> [3]  http://lists.gnu.org/archive/html/avr-gcc-list/2012-12/msg00029.html
  [4]  http://www.mail-archive.com/avr-gcc-list@nongnu.org/msg08215.html



-- 
All I kin say is when you finds yo'self wanderin' in a peach orchard,
ya don't go lookin' for rutabagas.
                                                          - Kingfish