https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112944
Bug ID: 112944
Summary: AVR: Support .rodata in Flash for Devices with FLMAP
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Devices from the AVR64* and AVR128* families (from avrxmega2 and avrxmega4)
see a 32 KiB portion of their program memory in the RAM address space.
Which 32 KiB segment is visible is determined by the bit-field
NVMCTRL_CTRLB.FLMAP.
This can be used to place .rodata in flash (it's currently located in RAM like
for all other AVR devices, except the ones from avrtiny and avrxmega3).
* The user should be able to chose the old .rodata location by means of
a command line option like, say -mrodata-in-ram. This is needed
to return to the current behaviour with rodata in RAM if desired.
* The user may chose which 32 KiB block holds the rodata section.
* In all cases, the default configurations should work correctly without any
user interventions / special code, irrespective of -m[no-]rodata-in-ram.
* The multilib structure is unchanged.
Locating .rodata in flash requires new linker description files which is
addressed by Binutils https://sourceware.org/PR31124.
The compiler part of the implementation is to:
* Add new command line options -m[no-]rodata-in-ram and -mflmap.
* Use the new / previous emulations according
to -mmcu=<mcu> and-m[no-]rodata-in-ram.
* Diagnose wrong usage of -m[no-]rodata-in-ram.
* Provide built-in macros __AVR_HAVE_FLMAP__ and __AVR_RODATA_IN_RAM__.
* Don't link __do_copy_data for .rodata objects.
