[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] Handling __flash1 and .trampolines [Was: .trampolines
Re: [avr-gcc-list] Handling __flash1 and .trampolines [Was: .trampolines location.]
Thu, 13 Dec 2012 00:04:10 +1100
On 11.12.12 14:42, Jan Waclawek wrote:
> There are several ways to approach that, as I wrote in the places I
> referred to before. For "segmented" access (i.e. ELPM with constant
> high address byte, which is what __flashN is about), you need to
> ensure that the data is located not below the 0xN0000 address (0x10000
> for __flash1).
AIUI, an AVR physical page starts _on_ 0xN0000, so that would seem to be
where __flashN has to start. When __memx is used, at least __flash1 must
be empty, IIUC what Johann so lucidly describes.
> At the same time, if .text reaches above 0xN0000, it should not
> overlap these data, rather, it should "push" them upwards.
AIUI, we use either 16-bit addressing, which is explicitly paged, or
24-bit addressing (__memx), which is not. In the latter case, the output
sections stack without effort, given a suitable linker script. In the
former, overlap must be detected.
> Alternatively, the data could be located in a reverse order from top
> of the segment. IMHO there's no support for either in the current
> linker (I am no ld guru so I may easily be wrong).
The required linker script modifications look eminently manageable so
far. It is cramming two contrary use cases into one linker script which
makes it less straightforward. (And therefore more interesting. :-)
Duct tape is like the force. It has a light side, and a dark side, and
it holds the universe together.
- Carl Zwanzig
|[Prev in Thread]
||[Next in Thread]|
- Re: [avr-gcc-list] Handling __flash1 and .trampolines [Was: .trampolines location.],
Erik Christiansen <=