[patch,avr] PR21472: Upgrade emulation avrxmega3 so it has .rodata in flash instead of in SRAM.

[Pitchumani Sivanupandi]

On Tuesday 09 May 2017 04:24 PM, Nick Clifton wrote:
> Hi Georg-Johann,
>
>>> On 09.05.2017 07:51, Senthil Kumar Selvaraj wrote:
>>> I'm still not convinced we need a new emulation for this.
> I would really prefer it if you two can come to an agreement about
> the best way to handle this.  I am not adverse to adding a new emulation
> if this is what you want, but I would be worried if this leads to an
> explosion in the number of linker scripts later on.
>
>
>> I don't see a way how to provide a linker description file without
>> supplying a new emulation.
> How about defining __RODATA_PM_OFFSET__ on the linker command line
> and using the current avrtiny.sc script ?
>
>
>>>> diff --git a/ld/emulparams/avrxmega3.sh b/ld/emulparams/avrxmega3.sh
>>>> index abaa5b3..504c492 100644
>>>> --- a/ld/emulparams/avrxmega3.sh
>>>> +++ b/ld/emulparams/avrxmega3.sh
>>>> @@ -1,6 +1,6 @@
>>>>   ARCH=avr:103
>>>>   MACHINE=
>>>> -SCRIPT_NAME=avr
>>>> +SCRIPT_NAME=avr_rodata
> I would much prefer it if you did not create a new script, but instead added
> parametrisation to the current avr and avrtiny scripts.  (In fact it would be
> even better if you could combine avr.sc and avrtiny.sc and just have one script).
>
> The reason for this is that the more scripts you have, the greater the chances
> of making an error or missing one out when it comes to future changes.
>
> Take a look at the elf.sc script.  It is used by lots of different targets, but
> it is highly customizable via definitions in the target's specific emulparams
> files.
>
> The alternative approach, which I would also consider to be reasonable, is to have
> a base avr script that defines all of the things that are consistent between all
> three proposed avr linker scripts and to include this script into smaller,
> avr-variant scripts that just defines those things that are specific to that variant.
> Kind of like how the DWARF.sc script is included into the elf.sc script.
We have tentative patch to put rodata in flash conditionally (e.g. 
option flag) that
seems to be working.

gcc:
Based on flag, put rodata in new section (tentatively named 
.rodataFlash). Also generates
new multilib (e.g. avrxmega2/flash-rodata) for architecture with 
-mflash-rodata flag.

Can enable this flag for devices with linear memory.

binutils:
It is similar to avrtiny change made to put rodata in flash. But the 
section name
is .rodataFlash. Sections named .rodata will go to data (i.e. 
-mflash-rodata not enabled).

avr-libc: change needed to identify the new multilib structure (to be done).

Tested following example with attiny817 simulator that comes with Atmel 
Studio.
   1 volatile int var;
   2 const short svar = 34;
   3 const char * const hello = "hello world";
   4 volatile char cvar[12];
   5 void main ()
   6 {
   7   while (1)
   8   {
   9     var  = svar;
  10     strcpy (cvar, hello);
  11   }
  12 }

$ avr-objdump -h test.elf

test.new.elf:     file format elf32-avr

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 .data         00000000  00803e00  000000b0  00000164  2**0
                   CONTENTS, ALLOC, LOAD, DATA
   1 .text         000000a0  00000000  00000000  000000b4  2**1
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   2 .rodataFlash  00000010  000080a0  000000a0  00000154  2**0
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   3 .bss          0000000e  00803e00  00803e00  00000164  2**0
                   ALLOC
   4 .stab         00000204  00000000  00000000  00000164  2**2
                   CONTENTS, READONLY, DEBUGGING
   5 .stabstr      0000009c  00000000  00000000  00000368  2**0
                   CONTENTS, READONLY, DEBUGGING
   6 .comment      00000029  00000000  00000000  00000404  2**0
                   CONTENTS, READONLY
   7 .note.gnu.avr.deviceinfo 0000003c  00000000  00000000  00000430 2**2
                   CONTENTS, READONLY

Regards,
Pitchumani
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flash_rodata_binutils.patch
Type: text/x-patch
Size: 1058 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20170510/361d3e38/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flash_rodata_gcc.patch
Type: text/x-patch
Size: 6613 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20170510/361d3e38/attachment-0001.bin>