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

[Jan Waclawek]

On Mon, 10 Dec 2012 23:33:37 +0100
Georg-Johann Lay <address@hidden> 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. 

Really. :-) It boils down to the definition of purpose of .progmem section.

> Problems arise if .trampolines is shifted out of the first
> 128KiB segment if .progmem gets too big.  

My view is, that .progmem should contain only data accessible through "plain" 
LPM (and related functions and macros in either avr-libc or generated by gcc 
for __flash), thus should never reach above the lowest (zeroth) 64kB FLASH 
"segment". That leaves ample space for .trampolines (and .jumptables and 
.lowtext, for whatever they were intended) in the first "segment".

> Notice that .trampolines is
> located *after* .progmem, thus a fix is to locate .trampolines before
> .progmem.

That would reduce the usable space for the data reachable through LPM, which is 
IMO unnecessary and harmful.

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


See above. Users should be taught to deliberately place data intended to be 
accessed through the "far-progmem" variants of avr-libc functions/macros into a 
dedicated section positioned *after* any program. See the example linker script 
attached to the above thread, and also in 
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=93874 .

I'd love to see support for such control in your implementatation of named 
address spaces (i.e. allowed combination of __memx and section attribute, or, 
more precisely, allowed typecasts into __memx-targeted pointers), but that's 
for another discussion.


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

This is exactly the hassle I am talking about...


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

Yes, but forcing the "high" data into "segments" is limiting in a certain way. 

In #26365 I am talking about two different approaches

* section for "far" data reaching from the lowest address not used by "low" 
data and program up to the highest available address in FLASH; to be accessed 
by ELPM with a potentially variable high byte

* 64kB segments to be accessed by ELPM with constant high byte

There are uses for both, IMO. __flash1 and kin implements only the second of 
them. This is limiting for many potential uses of the "high" flash space.

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

If the program (plus low progmem data) reaches above the 64k limit in a 128k 
device (if there's more FLASH, it may be easier to locate data starting from 
the highmost segment), my proposal is to place the high data into the 
non-segmented "progmem-far" section. While it may be hard to automate, a 
knowledgeable user may still attempt to make use of explicit knowledge of 
location of data for potentially more efficient access with constant high byte. 
Simple tools (scripts etc.) could be used during build to check that such data 
are inside the required segment. 

IMHO the key is a thorough documentation of whatever facilities are available.

I believe the >128k FLASH devices' users who would ever need to resort to these 
facilities are in minority; and most of them use the big FLASH mainly for 
extensive data with relatively small program (fitting below the 64k limit), so 
IMHO this issue does not deserve more attention than that.

JW