Re: [avr-gcc-list] Using Named Address spaces.

[Erik Christiansen]

Dang-nabit, there's a bug in the patch in the previous post. Maybe I should
have packed up earlier in the evening, before last minute changes.

Talking about testing, we also error explicitly if the user overflows
all of flash by grossly overflowing a flashN, other than the last:

$ avr-gcc -T avr6.x-test -Wl,-Map,flash.map -o flash.elf -DSTUBS=10 \
  -DP0=0x87ff -DP2=0x20000 -mmcu=atmega2560 flash.sx

../../../avr/bin/ld: Error: text overflows available flash memory.
../../../avr/bin/ld: Error: __flash2 (64KiB limit) overflow. Need to shrink it.
../../../avr/bin/ld: Error: text overflows available flash memory.
../../../avr/bin/ld: Error: __flash2 (64KiB limit) overflow. Need to shrink it.
../../../avr/bin/ld: Error: text overflows available flash memory.
../../../avr/bin/ld: Error: __flash2 (64KiB limit) overflow. Need to shrink it.

My prior reply to this:

> 2. If the linker scripts are made generic (Adding in scripttempl/avr.sc),
> can we control the number of flashN sections in the linker scripts as
> per the size of flash in the device ?

was too busy with why the existing script does not need customised
flashN counts, to concisely answer the question directly. We can do it.
If we move the .flashN output sections from the script template to being
generated by individual avr6X.sh files, then the number of pages will be
customised according to device. That still doesn't seem very useful to
me, though, since the excess empty .flashN sections harmlessly vanish if
not populated. Is there another reason for doing it, or do your
avr-objdump results not show that unpopulated .flashN sections vanish?
(With zero memory cost.)

Erik

-- 
What is this talk about releases? We do not make software "releases".         
Our software escapes, leaving a bloody trail of designers                     
and quality assurance people in its wake!                   - Klingons

avr6.x-new.patch
Description: Text document