This is an enhancement request. Memory controllers on embedded systems are getting increasingly complex, yet still without an MMU. This can mean that on some systems you can have some on-chip memory and some off-chip memory, but at non-contiguous addresses. Or for example on the Cortex-M4 based Freescale Kinetis, a region of on-chip SRAM which performs better for code, and the remainder performs better for data; code and data can go in either, but isn't cacheable in the "wrong" one. It would be useful if the linker could allow for input sections to be able to be spread over multiple output sections (located in specific MEMORY regions), in a way that allows us to say: "first use this region, then only if that fills up, use this other region". I have no fixed idea of syntax, but as a starting point, how about wrapping input sections with a special keyword, e.g.: ALLOW_MULTIPLE( <input section>, N ) where N is a number expressing the priority so that sections are filled in the correct order. Here's an example: MEMORY { ONCHIP : ORIGIN = 0x10000000, LENGTH=0x100000 OFFCHIP : ORIGIN = 0x20000000, LENGTH=0x100000 } SECTIONS { .text { ALLOW_MULTIPLE( *(.data.*), 100 ) } > ONCHIP .textoffchip { ALLOW_MULTIPLE( *(.data.*), 200 ) } > OFFCHIP .data { ALLOW_MULTIPLE( *(.data.*), 100 ) } > ONCHIP .dataoffchip { ALLOW_MULTIPLE( *(.data.*), 200 ) } > OFFCHIP } I think this would be very useful on quite a lot of embedded hardware, so please consider it. Thanks, Jifl
Aside from performance enhancement aspect of this issue there is a more sinister correctness issue associated with this problem. In the case of the cortex-m4 an attempt to perform an unaligned access across the boundary will result in a memory fault. A common use case is to aggregate the two regions into a single RAM bank (ignoring any potental performance optimization that might be had), in this scenario there is no obvious way to write a link script that fills up both RAM regions but ensures that no object is placed straddling the boundary. mbed-os and several other platform software implementations address this issue by writing a linker script that partitions the RAM into the two output regions and then manually hardwire input sections to the two output sections. This solution is fragile and regularly fails with the first region overflowing, resulting in further tweaks to the linker script. zephyr-os also have this issue and currently have no workaround.
commit abf874aafe3d71