avr-gcc-list
[Top][All Lists]
Advanced

[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




reply via email to

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