[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: |
Erik Christiansen |
Subject: |
Re: [avr-gcc-list] Handling __flash1 and .trampolines [Was: .trampolines location.] |
Date: |
Thu, 13 Dec 2012 00:04:10 +1100 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
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).
s/linker/linker script/
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. :-)
Erik
--
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] |
Current Thread |
[Next in Thread] |
- Re: [avr-gcc-list] Handling __flash1 and .trampolines [Was: .trampolines location.],
Erik Christiansen <=