Re: Handling __flash1 and .trampolines [Was: .trampolines location.]

Erik Christiansen schrieb:
> 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, \

.flash2 ?

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

Alignment is neither required nor enough.  The 2nd byte (the one loaded 
into RAMPZ) must match.  See the "subset" condition in the other post.

Currently, .text is located above .progmem, are you saying this must be 
swapped?  I think that will break existing code.

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


Sound really good.  Even if there is not possible (with reasonable 
effort) to support a feature, the linker should complain as much as 
possible if some assertion like .lowtext must be in the first 17-bit page.

Better complain as early as possible and don't generate non-functional code.

After that we can think about how to reduce the number of assertions. 
Or write documentation on how to arrange for setups with own linker scripts.

I still think that leaving the 16-bit space makes hardware oddness 
visible and enter user space.  We can hide some of it, but not 
everything.  This is the reason why progmem and __flash are there, for 
example.

Johann