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

[Georg-Johann Lay]

Erik Christiansen wrote:
> On 10.12.12 23:33, Georg-Johann Lay wrote:
>> 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.

Suppose flash1.c:


const int volatile __flash1 x = 1234;

int main (void)
{
  return x;
}


and compile with

$ avr-gcc flash1.c -mmcu=atmega128 -S -Os


main:
        ldi r30,lo8(x)
        ldi r31,hi8(x)
        ldi r18,1
        out __RAMPZ__,r18
        elpm r24,Z+
        elpm r25,Z+
        ret

.global x
        .section        .progmem1.data,"a",@progbits
        .type   x, @object
        .size   x, 2
x:
        .word   1234


This puts x into input section .progmem1.data and expects that this section is
located appropriately, in particular that  &x div 2^16  =  1

It allows to use 16-bit addresses in order to address 0x10000...0x1ffff,
similar for other __flashN.

However, .progmem1.data is not handled by the default linker script, i.e. will
match .progmem*

The preferred behavior is:

- Locate .progmem1.data at 0x10000

- Complain if data exceeds .progmem1.data and enters .progmem2.data

- Similar for .text

- Print diagnostics that are comprehensible, i.e. mention the input sections,
  that they overlap, and the symbol and object file that trigger the overlap.

- If .text spans from 0x0 to, say, 0x2aaaa, that's fine provided .progmem1.data
  and .progmem2.data are empty.


The __flashN spaces were introduced with __flash and because they are not much
more work than __flash.  I don't know if anybody is using that.

Alternative is __memx which implements 24-bit pointers.  Notice that
address-arithmetic is still 16-bit arithmetic.  Using __memx with the code
above, e.g.

$ avr-gcc flash1.c -mmcu=atmega128 -S -Os -D__flash1=__memx

yields:

main:
        ldi r24,lo8(x)
        ldi r25,hi8(x)
        ldi r26,hlo8(x)
        movw r30,r24
        mov r21,r26
        call __xload_2
        movw r24,r22
        ret

.global x
        .section        .progmem.data,"a",@progbits
        .type   x, @object
        .size   x, 2
x:
        .word   1234

Notice x is in .progmem.data now and an access function is used because hlo8(x)
is not known at compile time.

This means __memx can be regarded as extension of __flash.  Again, it is
reasonable to locate .trampolines early.  Because there is no limitation for
.progmem.data except that it must not exceed 0x7fffff because higher addresses
are taken as RAM or I/O locations.


Johann