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

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

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


From: Erik Christiansen
Subject: [avr-gcc-list] Handling __flash1 and .trampolines [Was: .trampolines location.]
Date: Tue, 11 Dec 2012 21:47:57 +1100
User-agent: Mutt/1.5.20 (2009-06-14)

On 10.12.12 23:33, Georg-Johann Lay wrote:
> Jan Waclawek schrieb:
> >Georg-Johann Lay wrote:
> >>* PR13812   .trampolines location in linker script cause
> >>"internal             error: out of range error"
> >>
> >>Dunno if this is still an issue resp. can be solved by a better
> >>default linker script.  Maybe a user-specific ld script is needed
> >>here, too.
> >
> >I'd say, this is not a bug, but abuse of the .progmem(.data) section,
> 
> Not really.  Problems arise if .trampolines is shifted out of the first
> 128KiB segment if .progmem gets too big.  Notice that .trampolines is
> located *after* .progmem, thus a fix is to locate .trampolines before
> .progmem.

Having always put trampolines before their destinations (on other
targets), that seems preferable, and a simple linker script tweak.
Is there any reason not to improve the default script in this regard?
Is any linker script help desired there?

...

> Basically #26365 addresses similar issues like PR14406 with the
> difference that the compiler already supports everything needed for data
> in __flash1 or higher, as avr-gcc calls is.
> 
> The trouble with that approach is that I found no way to express
> different flash usage scenarios in one linker script, e.g. you want to
> use segment #1 (2nd 64 KiB chunk) [A] for program or [b] for data.
> 
> Data for __flash1 will be put into input section .progmem1.data, but
> I found no way to describe that in the linker script.

What happens when you add a .progmem1.data input section? Your comments
above, and http://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html
suggest that significant (if not total) support exists. How does the
problem manifest?

I have not yet found whether a new fictitious absolute address range is
needed for location. That could readily be cobbled up in a linker
script, if that is the problem. (I don't use the big AVRs, so have only
google results to go on so far, for understanding the details.)

Is it possible to offer a little test case, so that we could try it, to
see where the wheels are falling off?

> Likely it's only because my very rudimentary ld-script skills.

If that is most of the problem, then it would be fun to have a go at it.
My ld skills grow rusty when not used, so a new problem is most welcome.

Erik

-- 
Tote Goldfische sind praktische Lesezeichen für Bücher aus der Leihbücherei.
Der wachsende Fischgeruch dient als einfache Gedächtnisstütze zur rechtzeitigen
Bücherrückgabe!                   (Snaffled from Christian Brabandt, on Vim ML)
= Dead goldfish are practical bookmarks for books from the library.
  The growing smell serves as a simple memory aid for timely return



reply via email to

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