Bug 14299 - Allow output sections to be spread over multiple memory regions
Summary: Allow output sections to be spread over multiple memory regions
Status: NEW
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: unspecified
: P2 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2012-06-26 18:57 UTC by Jonathan Larmour
Modified: 2017-02-23 07:48 UTC (History)
1 user (show)

See Also:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Larmour 2012-06-26 18:57:05 UTC
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:

    ONCHIP : ORIGIN = 0x10000000, LENGTH=0x100000
    OFFCHIP : ORIGIN = 0x20000000, LENGTH=0x100000
    .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.


Comment 1 Marcus Shawcroft 2017-02-23 07:48:18 UTC
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.