Hi Johann,
Hopefully my detailed reply to your beautiful explanatory example and
description of requirements, sent yesterday, has arrived. (Although it
still hasn't appeared on list. I'll post it there again, if it doesn't
show up after a full 24 hrs. I sent a copy to Jan, so he doesn't have to
wait, since he's interested.)
Please note that in that post, I ended up mimicking input section names
in at least one assertion, when intending to use output sections.
The construct will work better without the typo:
with_the_lot = ASSERT( SIZEOF(.text) <= 0x30000 && \
SIZEOF(.flash1) == 0 && SIZEOF(.flash1) == 0, \
"text segment (__memx) overflow!");
On fishing out the avr6.x linker script from binutils 2.23, I noticed
that we have:
/* For code that needs to reside in the lower 128k progmem. */
*(.lowtext)
*(.lowtext*)
Content of these input sections will start in page0 if it is not full,
and then just pile upwards, without heeding any page boundaries.
That seems more in line with Jan's description, than the clean __flashN
OR __memx (i.e. 16 or 24 bit worlds) I inferred from your description.
The goal now seems to be to let .text grow contiguously across pages, if
not obstructed by a __flashN page occupied by .progmemN.data. That means
that any occupied __flashN must be higher than _etext, to avoid overlap.
(And aligned to the 0x10000 page boundary.)
If you're happy with where we're headed, I'll construct and test a first
cut at an avr6.x, which handles __flashN, using discrete output
sections, and scripted overflow checking. In the meantime, I'll check
that a discarded (empty) output section doesn't have its VMA checked.
That'll be the easiest way to have each unoccupied __flashN slide out of
the way of the growing .text.
Then we can grow it for other use cases.
How does that sound?