TL;DR: Eric, there's a proposal for fixing the missing avr6 flash
overflow detection, in the second half of this post.
On 15.03.13 21:12, Erik Christiansen wrote:
> Why might a user deliberately choose to leave flash[1-4] unused? Each
> __flashN exists only for page alignment with EIND page selection, so it
> is most effective to use the pages in sequence, since all of memory is
> then used. If a user chooses to skip lower numbered flashN pages, then
> we must respect his explicit decision to reserve them for future use.
George, your question on back-filling flash[1-4] with arbitrary .text is
possibly more completely answered if we also look at some limitations
faced by ld.
Firstly, ld does not know that flash[1-4] are unoccupied, while it is
linking input sections according to the active script. Data and code
arrive willy-nilly, in whatever link order the user throws at ld. Until
linking is complete, any of flash[1-4] might at any time be populated by
a late xxx.o file. What information could ld use to decide to clobber
flash[1-4] with arbitrary .hightext?
Please note that the linker script _does_ populate any unutilised flashN
pages _above_ the last populated flashN page. It is only the deliberate
gap use-case which reserves memory.
Secondly, even if we did implement some way to promise to ld that
flash[1-4] would not be used for flashN, there remains the problem that
ld cannot flow code around memory holes. That feature has been requested
before, as in:
http://sourceware.org/ml/binutils/2012-01/msg00183.html
The reply to that post effectively rules out a backwards memory use
interpretation in our holey use case.
That only leaves memory reservation as a real-world purpose for
populating a high flashN, with lower flashN vacant, AFAICT.
---------------------- second half ----------------------
> I'll add illegal flashN detection. My (initial) plan is to base it on
> the size of flash specified.
Either accurate flash memory region sizes need to be specified, or
alternative detection limits (and an assertion) need to be merged into
the linker script template to provide silicon-relevant limits for each
avr6 device.
Currently, the avr6.x linker script specifies generic (essentially
limitless as far as the silicon is concerned) flash size:
MEMORY
{
text (rx) : ORIGIN = 0, LENGTH = 1024K
And that script is invoked if we specify -mmcu=atmega2560, which only
has 256 KB of flash. I.e. the linker script does not reflect the real
memory size, and so is too generic to detect text overflow or provide a
device-specific flashN limit. ####################
OK, how to fix?: As is done for avr5 and avr51 architectures, one way is
to provide a couple of avr6, avr61, avr62, ... architectures, with
silicon-relevant sizes for text length, data origin, and data length.
That will fix the current failure to detect flash overflow. For that we
would need a simple table of current avr6 devices:
Device Architecture Flash_size RAM_Origin RAM_size
-----------------------------------------------------------
generic avr6 1024k 0x800200 0xfe00
Atmega2560 avr61 256k 8k
Atmega...
Atmega...
-----------------------------------------------------------
Here are some avr5 examples, for comparison:
Atmega1280 avr5 128k 0x800060 0xffa0
Atmega.... avr51 128k 0x800100 0xff00
-----------------------------------------------------------
Then I could whip up a bunch of tiny avr6X.sh files to munge *one*
avr6.sc script template into a custom linker script for each avr6
architecture that you think we need. (If Anatoly is still across the
config/avr/t-multilib end of it, I'll willingly stick to the linker
script template stuff.)
Now, what about flagging illegally high flashN? If you (and Eric) are
happy with handling the avr6 architecture spectrum in the same way as
avr5 and avr51 have been done, plus the new script template, then the
errors are detected by ld, without additional scripting.
But ld's default error messages can be ugly, as we see after just
customising for the Atmega2560 in avr6.x-new:
MEMORY
{
text (rx) : ORIGIN = 0, LENGTH = 256K
Now we detect that overflow occurs first, due to a populated .hightext:
$ avr-gcc -T avr6.x-test -Wl,-Map,flash.map -o flash.elf -DSTUBS=10
-DP0=0x87ff -DP3=0x10000 -mmcu=atmega2560 flash.sx
../avr/bin/ld: flash.elf section `.hightext' will not fit in region `text'
../avr/bin/ld: region `text' overflowed by 98 bytes
Placing a flashN beyond available flash is just another form of
overflow:
$ avr-gcc -T avr6.x-test -Wl,-Map,flash.map -o flash.elf -DSTUBS=10
-DP0=0x87ff -DP4=0x10000 -mmcu=atmega2560 flash.sx
../avr/bin/ld: address 0x50000 of flash.elf section `.flash4' is not within
region `text'
../avr/bin/ld: flash.elf section `.hightext' will not fit in region `text'
../avr/bin/ld: address 0x50000 of flash.elf section `.flash4' is not within
region `text'
../avr/bin/ld: region `text' overflowed by 65634 bytes
Now ld is annoyinly prolix, but the very first grumble tells us that
`.flash4' is the problem.
For control over error messages, we could leave the text size at 1024K,
and employ a couple of assertions (see attached patch) to improve
reporting for the previous two cases, repeated here:
$ avr-gcc -T avr6.x-test -Wl,-Map,flash.map -o flash.elf -DSTUBS=10
-DP0=0x87ff -DP3=0x10000 -mmcu=atmega2560 flash.sx
../avr/bin/ld: Error: text + data overflows available flash memory.
../avr/bin/ld: Error: text + data overflows available flash memory.
../avr/bin/ld: Error: text + data overflows available flash memory.
$ avr-gcc -T avr6.x-test -Wl,-Map,flash.map -o flash.elf -DSTUBS=10
-DP0=0x87ff -DP4=0x10000 -mmcu=atmega2560 flash.sx
../avr/bin/ld: Error: FlashN page placed beyond available flash memory.
../avr/bin/ld: Error: text + data overflows available flash memory.
../avr/bin/ld: Error: FlashN page placed beyond available flash memory.
../avr/bin/ld: Error: text + data overflows available flash memory.
../avr/bin/ld: Error: FlashN page placed beyond available flash memory.
../avr/bin/ld: Error: text + data overflows available flash memory.
To make that work, we still need an xxx.sh file per architecture, to
customise the assertions provided by the script template. I'll do that
if the better error messages are the way to go. The repetition is
characteristic of ld, and we'd have to delve into its code to tidy that
up, I suspect.
We could start with just a few devices in the table, and add more later,
but that could lead to inconsistent architecture numbering, unless we
start with the small ones.
Hopefully that clarifies some doubts about ld's limitations. Our linker
script can do anything that ld can do in this context, AFAICT.
Is the customised error messaging on flash overflow, and illegal flashN,
worth going for? (The necessary changes would include some avr6X.sh
files, to handle multiple avr6 variants, but the attached avr6.x-new
patch shows the look.)
Erik
--
Habit is habit, and not to be flung out of the window by any man, but
coaxed down-stairs a step at a time.
- Mark Twain, "Pudd'nhead Wilson's Calendar
-- avr6.x-new 2012-12-16 23:56:51.000000000 +1100
+++ avr6.x-test 2013-03-16 22:43:30.000000000 +1100
@@ -1,6 +1,7 @@
/* Default linker script, for normal executables */
OUTPUT_FORMAT("elf32-avr","elf32-avr","elf32-avr")
OUTPUT_ARCH(avr:6)
+__total_text = 256K ;
MEMORY
{
text (rx) : ORIGIN = 0, LENGTH = 1024K
@@ -124,6 +125,8 @@ SECTIONS
.hightext :
{
+ x = ASSERT (. <= __total_text, "Error: FlashN page placed beyond available
flash memory.") ;
+
/* The following is OK to follow preceding sections
at any even byte address, on any page. */
@@ -190,6 +193,9 @@ SECTIONS
_edata = . ;
PROVIDE (__data_end = .) ;
} > data
+
+ x = ASSERT (. <= __total_text, "Error: text + data overflows available
flash memory.") ;
+
.bss : AT (ADDR (.bss))
{
PROVIDE (__bss_start = .) ;
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
