Re: [avr-gcc-list] .trampolines location. Was: Current patch queue against binutils upstream

[Georg-Johann Lay]

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.

> to be resolved by enhanced documentation and adding dedicated "high 
> progmem" section(s) into the linker script. I "asked" for such in 
> https://savannah.nongnu.org/bugs/?26365 , I am unable to resolve the

AFAIK see that is related to non-volatile data in flash, not to linker
stubs?

> details myself. Some diagnostic/warning issued by linker would be 
> nice but is not worth the hassle, IMHO.

I wonder how the linker can know? In order to tell anything about this,
it would need more information, e.g. specific section flags or similar. 
 Currently there is no means to tell the linker: How could the linker 
tell if you wrote PSTR or PSTRX or whatever?

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.

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

> [...] I won't comment in the binutils tracker, as this is a highly
> personal view and I believe many will find it controversial.

Sorry? I don't understand what you write.

Johann