https://sourceware.org/bugzilla/show_bug.cgi?id=31124
Bug ID: 31124
Summary: AVR: Support new Emulations for devices with FLMAP
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot 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.
* Provide symbols so that the startup code from AVR-LibC is able to set
up NVMCTRL_CTRLB.FLMAP that controls which 32 KiB block is visible in
the RAM address space.
* New (default) linker description files are needed. This requires new
emulations like avrxmega2_flmap and avrxmega4_flmap.
* The startup-code from AVR-LibC should work irrespective of the chosen
emulation, so that we retain the one-crt-per-device policy for simplicity.
* 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.
--
You are receiving this mail because:
You are on the CC list for the bug.
