[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.]
Tue, 11 Dec 2012 14:42:00 +0100
>> >>* 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
>Having always put trampolines before their destinations (on other
progmem does not contain destinations of stubs in .trampolines. And I don't see
how experience from other targets would be pertinent to this particular issue.
Are you familiar with the intended use of these sections in avr-gcc and
> that seems preferable, and a simple linker script tweak.
>Is there any reason not to improve the default script in this regard?
It is not an *improvement*, it is a *change* with potentially detrimetal effect
(reduced .usable "low progmem data" space. Have you read my previous answer to
>> 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?
Do you have experience with using >64kB constant data in FLASH?
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). At the same time, if
.text reaches above 0xN0000, it should not overlap these data, rather, it
should "push" them upwards. 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).
|[Prev in Thread]
||[Next in Thread]|
- Re: [avr-gcc-list] Handling __flash1 and .trampolines [Was: .trampolines location.],
Jan Waclawek <=