[patch,avr] PR21849: Locate section .progmemx.* at a higher address.

[Georg-Johann Lay]

On 27.07.2017 13:48, Nick Clifton wrote:
> Hi Johann,
> 
>> Hi, this fixes PR21849:  The current location of data for
>> avr-gcc named address space __memx is such that it "wastes"
>> lower addresses in the 16-bit range.
>>
>> As the compiler is using 24-bit addresses for __memx data which
>> it located in .progmemx.*, this section can be moved to a higher
>> address in the linker script.
> 
>> @@ -128,7 +128,7 @@ SECTIONS
>>       ${RELOCATING+ *libprintf_flt.a:*(.progmem.data)}
>>       ${RELOCATING+ *libc.a:*(.progmem.data)}
>>   
>> -    ${RELOCATING+ *(.progmem*)}
>> +    ${RELOCATING+ *(.progmem.*)}
>>       
>>       ${RELOCATING+. = ALIGN(2);}
>>   
>> @@ -196,6 +196,8 @@ SECTIONS
>>       *(.hightext)
>>       ${RELOCATING+ *(.hightext*)}
>>   
>> +    ${RELOCATING+ *(.progmemx.*)}
>> +
>>       ${RELOCATING+. = ALIGN(2);}
>>   
>>       /* For tablejump instruction arrays.  We don't relax
> 
> This does not look right.  It does add the .progmemx.* entry to the high area
> but it also removes the .progmem.* entry from the low area.  Why is this needed ?
> .progmem.* will not match any .progmemx.* sections, so the two are distinct.

There is

+    ${RELOCATING+ *(.progmem.*)}

at the low end.  avr-gcc only generates .progmem.data (or .progmem.gcc*
for old versions) so that .progmem.* catches them all without matching
.progmemx.*

> (Note the period character in a section pattern is not a regexp character, it
> exactly matches only the period character itself).
> 
>> Would also be great if this can go into 2.29.
> 
> Sorry - 2.29 is out of the door - so it is too late for this to happen.
> 
> Cheers
>    Nick

What I meant is back-porting to the 2.29 branch so it will come with 2.29.*.

Johann