On 13.12.12 14:26, Georg-Johann Lay wrote:
> Here is more torture.
Thank you. That significantly speeded up trying the following use cases.
After making a list of requirements from upthread¹, and further
modifying the linker script to squeeze __flashN in between .lowmem and
.text, here's some sample initial test results for some of the linker
script changes. Please point out anything that does not accord with the
requirements.
Req:
Error detection on .trampolines, .progmem*, or .lowmem, overflowing 128KiB.
Test: Overflow the low 128 KiB:
$ avr-gcc -T avr6.x-new -Wl,-Map,flash.map -o flash.elf -DSTUBS=10 \
-DP0=0x20000 -DTEXT=0x20000 -mmcu=atmega2560 flash.sx
Result:
"../avr/bin/ld: Error: .lowtext (128KiB limit) overflow. Try shrinking
.progmem?"
The message is repeated, apparently once for each following empty
__flashN output section. We'll try to find a way to improve the
aesthetics.
The desired error message was also initially preceded by an "internal
error: out of range error" on each stub, as they were pushed over the
128KiB edge. So I've moved .progmem.data* to the end of the output
sction, thus cleaning up the error messages significantly.
Req: Locate .progmemN.data at 0xN0000, and flag overlaps.
Test: Overlap two __flashN:
$ avr-gcc -T avr6.x-new -Wl,-Map,flash.map -o flash.elf -DSTUBS=10 \
-DP1=0x18000 -DP2=0x10000 -DTEXT=0x20000 -mmcu=atmega2560 flash.sx
Result:
../avr/bin/ld: section .flash2 loaded at [00020000,0002ffff] overlaps
section .flash1 loaded at [00010000,00027fff]
../avr/bin/ld: flash.elf: section .flash2 vma 0x20000 overlaps previous
sections
../avr/bin/ld: flash.elf: section .hightext vma 0x30000 overlaps
previous sections
The last line seems to be like a gcc consequential error. We have to
clean up the first one before we can know it didn't cause the last one.
Test: Locate two __flashN, without overlap:
$ avr-gcc -T avr6.x-new -Wl,-Map,flash.map -o flash.elf -DSTUBS=10 \
-DP1=0x8000 -DP2=0x10000 -DTEXT=0x20000 -mmcu=atmega2560 flash.sx
Result:
Sections:
Idx Name Size VMA LMA File off Algn
0 .data 00000000 00800200 00050062 00038222 2**0
CONTENTS, ALLOC, LOAD, DATA
1 .lowtext 0000010c 00000000 00000000 000000b4 2**1
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .flash1 00008000 00010000 00010000 000001c0 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .flash2 00010000 00020000 00020000 000081c0 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .hightext 00020062 00030000 00030000 000181c0 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
The trampolines etc. in .lowtext go from 0 to 0x10c.
We see .flash1 at 00010000, and .flash2 at 00020000, as required.
The rest of .text butts up to the end of .flash2.
And the LMA of .data butts up to the end of .hightext, at
00030000 + 00020062 = 00050062
That leaves only the holes specified by the user, before each .flashN.
And if there are no __flashN, it concertinas further, as Jan told us it
should:
$ avr-gcc -T avr6.x-new -Wl,-Map,flash.map -o flash.elf -DSTUBS=10 \
-DTEXT=0x20000 -mmcu=atmega2560 flash.sx
Sections:
Idx Name Size VMA LMA File off Algn
0 .data 00000000 00800200 0002016e 000201e2 2**0
CONTENTS, ALLOC, LOAD, DATA
1 .lowtext 0000010c 00000000 00000000 00000074 2**1
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .hightext 00020062 0000010c 0000010c 00000180 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
The trampolines etc. in .lowtext go from 0 to 0x10c.
The rest of .text, i.e. .hightext, now butts up to the end of
.lowtext, at 0x10c.
And the LMA of .data butts up to the end of .hightext, at
00020062 + 0000010c = 0002016e
Why are we checking .data LMA? Because the expression for that had to be
tweaked for the new script architecture. (And it was made simpler,
rather than yet more complicated. That needs double checking.)
Please try some other use cases, to see if any further tweaking is
needed already now. Often, more requirements come to light at this
stage. Perhaps more error detection?
The linker script patch is appended below.
Erik
¹ Where it did explain why it's 2^17. I've been away from AVRs for too
long.
file: avr6.patch
--- avr6.x-2.23 2012-12-13 13:42:18.000000000 +1100
+++ avr6.x-new 2012-12-15 14:12:07.000000000 +1100
@@ -70,13 +70,12 @@
.rel.plt : { *(.rel.plt) }
.rela.plt : { *(.rela.plt) }
/* Internal text space or external memory. */
- .text :
+ .lowtext :
{
*(.vectors)
KEEP(*(.vectors))
/* For data that needs to reside in the lower 64k of progmem. */
*(.progmem.gcc*)
- *(.progmem*)
. = ALIGN(2);
__trampolines_start = . ;
/* The jump trampolines for the 16-bit limited relocs will reside here. */
@@ -98,6 +97,25 @@
__dtors_end = . ;
KEEP(SORT(*)(.ctors))
KEEP(SORT(*)(.dtors))
+ *(.progmem.data*) /* Explicitly page 0 input sections */
+ _elowtext = . ;
+ x = ASSERT (. < 0x20000, "Error: .lowtext (128KiB limit) overflow. Try
shrinking .progmem?") ;
+ } > text
+
+ .flash1 0x10000 :
+ { *(.progmem1.data*) /* Page 1 */
+ } > text
+
+ .flash2 0x20000 :
+ { *(.progmem2.data*) /* Page 2 */
+ } > text
+
+ .flash3 0x30000 :
+ { *(.progmem3.data*) /* Page 3 */
+ } > text
+
+ .hightext :
+ {
/* From this point on, we don't bother about wether the insns are
below or above the 16 bits boundary. */
*(.init0) /* Start here after reset. */
@@ -146,7 +164,8 @@
KEEP (*(.fini0))
_etext = . ;
} > text
- .data : AT (ADDR (.text) + SIZEOF (.text))
+
+ .data : AT (_etext)
{
PROVIDE (__data_start = .) ;
/* --gc-sections will delete empty .data. This leads to wrong start
--
Any project you tackle is always hardest at the beginning, like working
up a swing. - P.K. Shaw
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
