The first attempt to handle __flashN seems to be achieving what I
understand to be the requirements, as far as basic testing shows.
Please try to rip its arms off, so we can give it the robustness which
users need. (Also, what have I plain missed. ;-)
Here are two test cases based on one source code example compared with
Johann's requirements for the script behaviour.
On 11.12.12 17:47, Georg-Johann Lay wrote:
> However, .progmem1.data is not handled by the default linker script, i.e. will
> match .progmem*
To handle that and __flashN up to 3 (for starters), here is a patch for
the avr6.x linker script from binutils 2.23:
--- avr6.x-2.23 2012-12-13 13:42:18.000000000 +1100
+++ avr6.x-new 2012-12-13 20:27:33.000000000 +1100
@@ -76,7 +76,7 @@
KEEP(*(.vectors))
/* For data that needs to reside in the lower 64k of progmem. */
*(.progmem.gcc*)
- *(.progmem*)
+ *(.progmem.data) /* Explicitly page 0 input section */
. = ALIGN(2);
__trampolines_start = . ;
/* The jump trampolines for the 16-bit limited relocs will reside here. */
@@ -146,6 +146,19 @@
KEEP (*(.fini0))
_etext = . ;
} > text
+
+ .flash1 0x10000 :
+ { *(.progmem1.data) /* Page 1 */
+ } > text
+
+ .flash2 0x20000 :
+ { *(.progmem2.data) /* Page 2 */
+ } > text
+
+ .flash3 0x30000 :
+ { *(.progmem3.data) /* Page 3 */
+ } > text
+
.data : AT (ADDR (.text) + SIZEOF (.text))
{
PROVIDE (__data_start = .) ;
Handling more __flashN is just copy, paste, increment 4 digits.
Now to compare the performance of this script with the preferred
behaviour, using source with 66k of .text, so that it overlaps
__flash1. But then we only occupy __flash2, to test that an empty
__flash1 silently steps out of the way of a growing .text for us:
file: flashN_test.S
.section .text
.rept 33000 # Simulate 33k code
.byte 1
.endr
.section .progmem.data,"a",@progbits
.rept 33000 # Simulate 33k __flash
.byte 2
.endr
.section .progmem2.data,"a",@progbits
.rept 330 # Simulate 330 __flash2
.byte 3
.endr
That overlaps .text a couple of k onto __flash1 space.
__flash2 must start at 0x20000.
> The preferred behavior is:
>
> - Locate .progmem1.data at 0x10000
That happens when __flash1 is occupied. Beginning with the tougher case
of __flash2 located at 0x20000, with _flash1 at 0x10000, but unoccupied,
so not allowed to error when .text grows over it, we do:
$ avr-as -alcmns -mmcu=avr6 flashN_test.S -o flashN_test.o > flashN_test.lst
$ avr-ld -M -T avr6.x-new -o flashN_test.elf flashN_test.o > flashN_test.map
$ avr-objdump -h flashN_test.elf
It works as expected. Although text has a size of 0x000101d0 (66k), which
extends into __flash1 space, there are no error messages from avr-ld,
because __flash1 is empty. Our 0x14a (330) bytes of __flash2 has a VMA
of 0x20000, as required for a RAMPZ 0f 2:
flashN_test.elf: file format elf32-avr
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 000101d0 00000000 00000000 00000094 2**1
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .flash2 0000014a 00020000 00020000 00010264 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .data 00000000 00800200 000101d0 00010264 2**0
CONTENTS, ALLOC, LOAD, DATA
> - Complain if data exceeds .progmem1.data and enters .progmem2.data
OK, to test that, we change the last .section directive in the source to:
.section .progmem1.data,"a",@progbits
Now .text overlaps __flash1, showing that it has materialised at 0x10000.
The linker invocation now errors:
/usr/local/avr/bin/avr-ld: section .flash1 loaded at [00010000,00010149] \
overlaps section .text loaded at [00000000,000101cf]
For this use case, ld's inbuilt erroring seems sufficient. (Well, it's
what I'm used too. :-)
> - Similar for .text
Well, we have just tested that one instead, because that's the picture I
had in my mind.
> - Print diagnostics that are comprehensible, i.e. mention the input sections,
> that they overlap, and the symbol and object file that trigger the overlap.
My earlier post, not yet on the list server, though CCed to it,
discusses the impracticability of expecting input sections to be known
when locating. If more is needed, we'll have to discuss what is practicable.
> - If .text spans from 0x0 to, say, 0x2aaaa, that's fine provided
> .progmem1.data
> and .progmem2.data are empty.
What worked, above, for one empty output section (above) will work for several
in
a row, I anticipate.
>
> 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.
I've only included up to __flash2, to keep this email shorter. We'll add
them all, if you're happy with where we're headed.
> 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.
I'll look at that once __flashN is done, I figure.
If that is approaching usefulness, what extra stuff do you need, to
complete the wishlist?
Erik
--
Give a man a gun and he can rob a bank.
Give a man a bank and he can rob the world.
- Seen on http://jyllands-posten.dk/
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
