[Bug target/112944] New: AVR: Support .rodata in Flash for Devices with FLMAP

[Bug target/112944] New: AVR: Support .rodata in Flash for Devices with FLMAP

[gjl at gcc dot gnu.org]

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.

[Bug target/112944] AVR: Support .rodata in Flash for Devices with FLMAP

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112944

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |gjl at gcc dot gnu.org
             Target|                            |avr
   Target Milestone|---                         |14.0
           Severity|normal                      |enhancement
           Priority|P3                          |P4

[Bug target/112944] AVR: Support .rodata in Flash for Devices with FLMAP

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112944

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-12-15
             Status|UNCONFIRMED                 |ASSIGNED

[Bug target/112944] AVR: Support .rodata in Flash for Devices with FLMAP

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112944

--- Comment #1 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Georg-Johann Lay <gjl@gcc.gnu.org>:

https://gcc.gnu.org/g:48448055fb70862ff3914f8a714ff5c4128e6ced

commit r14-7231-g48448055fb70862ff3914f8a714ff5c4128e6ced
Author: Georg-Johann Lay <avr@gjlay.de>
Date:   Thu Jan 11 22:11:25 2024 +0100

    AVR: Support .rodata in Flash for AVR64* and AVR128* Devices.

    These devices see a 32 KiB block of their program memory (flash) in
    the RAM address space.  This can be used to support .rodata in flash
    provided Binutils support PR31124 (Add new emulations which locate
    .rodata in flash).  This patch does the following:

    * configure checks availability of Binutils PR31124.

    * Add new command line options -mrodata-in-ram and -mflmap.
    While -flmap is for internal usage (communicate hardware properties
    from device-specs to the compiler proper), -mrodata-in-ram is a user
    space option that allows to return to the current rodata-in-ram layout.

    * Adjust gen-avr-mmcu-specs.cc so that device-specs are generated
    that sanity check options, and that translate -m[no-]rodata-in-ram
    to its emulation.

    * Objects in .rodata don't drag __do_copy_data.

    * Document new options and built-in macros.

            PR target/112944

    gcc/
            * configure.ac [target=avr]: Check availability of emulations
            avrxmega2_flmap and avrxmega4_flmap, resulting in new config vars
            HAVE_LD_AVR_AVRXMEGA2_FLMAP and HAVE_LD_AVR_AVRXMEGA4_FLMAP.
            * configure: Regenerate.
            * config.in: Regenerate.
            * doc/invoke.texi (AVR Options): Document -mflmap, -mrodata-in-ram,
            __AVR_HAVE_FLMAP__, __AVR_RODATA_IN_RAM__.

            * config/avr/avr.opt (-mflmap, -mrodata-in-ram): New options.
            * config/avr/avr-arch.h (enum avr_device_specific_features):
            Add AVR_ISA_FLMAP.
            * config/avr/avr-mcus.def (AVR_MCU) [avr64*, avr128*]: Set isa flag
            AVR_ISA_FLMAP.
            * config/avr/avr.cc (avr_arch_index, avr_has_rodata_p): New vars.
            (avr_set_core_architecture): Set avr_arch_index.
            (have_avrxmega2_flmap, have_avrxmega4_flmap)
            (have_avrxmega3_rodata_in_flash): Set new static const bool
according
            to configure results.
            (avr_rodata_in_flash_p): New function using them.
            (avr_asm_init_sections): Let
readonly_data_section->unnamed.callback
            track avr_need_copy_data_p only if not avr_rodata_in_flash_p().
            (avr_asm_named_section): Track avr_has_rodata_p.
            (avr_file_end): Emit __do_copy_data also when avr_has_rodata_p
            and not avr_rodata_in_flash_p ().
            * config/avr/specs.h (CC1_SPEC): Add %(cc1_rodata_in_ram).
            (LINK_SPEC): Add %(link_rodata_in_ram).
            (LINK_ARCH_SPEC): Remove.
            * config/avr/gen-avr-mmcu-specs.cc (have_avrxmega3_rodata_in_flash)
            (have_avrxmega2_flmap, have_avrxmega4_flmap): Set new static
            const bool according to configure results.
            (diagnose_mrodata_in_ram): New function.
            (print_mcu): Generate specs with the following changes:
            <*cc1_misc, *asm_misc, *link_misc>: New specs so that we don't
            need to extend avr/specs.h each time we add a new bell or whistle.
            <*cc1_rodata_in_ram, *link_rodata_in_ram>: New specs to diagnose
            -m[no-]rodata-in-ram.
            <*cpp_rodata_in_ram>: New. Does -D__AVR_RODATA_IN_RAM__=0/1.
            <*cpp_mcu>: Add -D__AVR_AVR_FLMAP__ if it applies.
            <*cpp>: Add %(cpp_rodata_in_ram).
            <*link_arch>: Use emulation avrxmega2_flmap, avrxmega4_flmap as
            requested.
            <*self_spec>: Add -mflmap or %<mflmap as needed.

    gcc/testsuite/
            * gcc.target/avr/torture/pr112944-flmap-0.c: New test.
            * gcc.target/avr/torture/pr112944-flmap-1.c: New test.

[Bug target/112944] AVR: Support .rodata in Flash for Devices with FLMAP

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112944

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #2 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
Implemented in v14.

[Bug target/112944] AVR: Support .rodata in Flash for Devices with FLMAP

[gjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112944

--- Comment #3 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
See also the GCC v14 Release Notes:

https://gcc.gnu.org/gcc-14/changes.html#avr

[Bug target/112944] AVR: Support .rodata in Flash for Devices with FLMAP

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112944

--- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Georg-Johann Lay <gjl@gcc.gnu.org>:

https://gcc.gnu.org/g:525cfe1e9554858366e7811aa9e437357c0f272e

commit r14-8926-g525cfe1e9554858366e7811aa9e437357c0f272e
Author: Georg-Johann Lay <avr@gjlay.de>
Date:   Mon Feb 12 11:10:48 2024 +0100

    AVR: target/112944 - Addendum: Link code to initialize NVMCTRL_CTRLB.FLMAP

    For devices that see a part for the flash memory in the RAM address space,
    bit-field NVMCTRL_CTRLB.FLMAP must match the value of symbol __flmap.
    This is achieved by dragging in startup code from lib<mcu>.a.
    The mechanism is the same like for libgcc's __do_copy_data and
__do_clear_bss.
    The code is implemented in AVR-LibC #931 and can be dragged by referencing
    __do_flmap_init.

    In addition to setting FLMAP, that code also sets bit FLMAPLOCK provided
    symbol __flmap_lock has a non-zero value.  This protects FLMAP from future
    changes.

    When the __do_flmap_init code is not wanted, the symbol can be satisfied by
    linking with  -Wl,--defsym,__do_flmap_init=0

    gcc/
            PR target/112944
            * config/avr/gen-avr-mmcu-specs.cc (print_mcu) [have_flmap]:
            <*link_rodata_in_ram>: Spec undefs symbol __do_flmap_init
            when not linked with -mrodata-in-ram.