Re: Handling __flash1 and .trampolines [Was: .trampolines location.]

>> >>* 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),

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 avr-libc?

> 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 Johann's post?


>> 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).

JW