public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "gjl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/112944] New: AVR: Support .rodata in Flash for Devices with FLMAP Date: Sun, 10 Dec 2023 12:01:52 +0000 [thread overview] Message-ID: <bug-112944-4@http.gcc.gnu.org/bugzilla/> (raw) 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.
next reply other threads:[~2023-12-10 12:01 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-12-10 12:01 gjl at gcc dot gnu.org [this message] 2023-12-10 12:15 ` [Bug target/112944] " gjl at gcc dot gnu.org 2023-12-15 20:37 ` gjl at gcc dot gnu.org 2024-01-14 18:11 ` cvs-commit at gcc dot gnu.org 2024-01-14 18:13 ` gjl at gcc dot gnu.org 2024-02-01 16:38 ` gjl at gcc dot gnu.org 2024-02-12 11:04 ` cvs-commit at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-112944-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).