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
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
