[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Handling __flash1 and .trampolines [Was: .trampolines

From: Georg-Johann Lay
Subject: Re: [avr-gcc-list] Handling __flash1 and .trampolines [Was: .trampolines location.]
Date: Thu, 13 Dec 2012 12:24:06 +0100
User-agent: Thunderbird (Windows/20100228)

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]