I’m very interested in this as well but want to point out that there are often performance implications of the different memory regions. I think it’s the linker’s job to know about these trade-offs.
We’re starting to use the iMX RT for CircuitPython, which is a Python VM on bare metal. The iMX RT are a Cortex-M7 core clocked between 400 and 1000 MHz. There are basically three tiers of memory:
- Tightly coupled memory (TCM) runs at the core speed.
- OCRAM runs at 1/4 core speed or less but is accessible to more peripherals.
- Execute in place (XIP) flash. Much slower than RAM but much larger. (SPI flash running at 120 MHz and four bits per clock.) A user modifiable file system is also on the flash and programming it prevents XIP access temporarily.
2 and 3 may be accessed through a cache that runs at core speed too. The cache’s are of limited size between 8 and 32k. TCM sizes are configurable between 32k and 256k depending on the part.
Function calls between 1 and 3 cause “veneer” or “trampoline” code to bridge the wide address space gap.
In CircuitPython, the VM portions are always used by user code but peripheral specific functionality may not be. Currently, we use linker scripts with binutils to place in the different regions. We want VM code in TCM because it always is used and needs to be fast. (The error handling portions could be in XIP.) Code that runs while flash is disabled to always be in RAM (maybe TCM). All of the “user code may use this” code should live on flash and hopefully 
stay in cache once loaded.
So, ideally the linker would place all explicit sections into TCM first (due to hazards likely) and then fill the rest of the space with the hottest code first. That’d allow us to have one linker script apply across varying TCM sizes.
Note, that there is a separate issue with using sections to designate functions that need to be in RAM because the linker will happily link those to functions and/or data in the region of memory that is supposedly inaccessible.