Re: [RFC] Allow linker scripts to specify multiple output regions for an output section?

[Erik Christiansen <dvalin at internode dot on dot net>]

On 27.06.19 14:58, Christophe Lyon wrote:
> On Fri, 9 Jun 2017 at 15:35, Erik Christiansen <dvalin@internode.on.net> wrote:
> > On 09.06.17 13:20, Tejas Belagod wrote:
> > > > > I agree that replacing the first-match rule with a subsequent match rule
> > > > > controlled by a command-line switch is much much lower implementation cost.
> > > > > It will be interesting to hear views of a maintainer about the preferred
> > > > > approach.
> > ...

> We have received requests to support non-contiguous memory regions in
> the BFD linker, so it seems it is time to resurrect this thread :-)
> 
> IIUC, Erik made a proposal that seems simpler to implement than the
> initial one in
> https://sourceware.org/ml/binutils/2017-03/msg00020.html
> 
> Tejas, on your side, do you have any news about this project? (ideally
> in terms of implementation, but updated specs would be good too)

Having not heard from Tejas or Thomas since the on-list posts in 2017,
the closest I can offer to draft specs is a summary of my recollection
of the consensus reached:

A memory region with a hole is identical to two non-contiguous memory
regions, if flowing of input sections preempts the linker's existing
overflow detection. Existing linker script syntax can specify the
regions, but the flowing is currently lacking. Flowing should occur when
the remaining space in a region cannot accommodate the next full input
section about to be allocated, and the current input section matches a
pattern in a subsequent output section, directed to another memory
region. The comparison is (LENGTH - SIZEOF) vs input section size, as we
have a 1:1 correspondence between output section and memory region for
flow steering, anyway.)

Flowing granularity is full input sections. That avoids needing to
rework relocations within an input section, due to flowing. Care may
need to be taken to still invoke existing linker code to provide
(default or explicit) FILL to the memory remnant. (I.e. slip it in
before resuming allocation in the next region.)

A command line switch would usefully protect against any backward linker
script incompatibility.

A new refinement?: The required search for a second pattern match might
be more simply implemented by remembering the output section in which
the first match was found, and when needing a second match, resuming the
search from the following output section. When available subsequent
matches are exhausted, the existing overflow detection is finally
reached, giving consistent behaviour.

The simplified implementation does not require modification of linker
script syntax. It also allows explicit placement of chosen input
sections in a preferred memory section. In addition to simple flowing of
*(.data) *(.data.*):

MEMORY
{
  RAML (rwx) : ORIGIN = 0x1FFF0000, LENGTH = 0x00010000
  RAMU (rwx) : ORIGIN = 0x20000000, LENGTH = 0x00040000
  RAMZ (rwx) : ORIGIN = 0x20040000, LENGTH = 0x00040000
}

SECTIONS
{
   .raml : AT ( ADDR (.text) + SIZEOF (.text) )
   {  _rmal_start = . ;
      *(.boot) ;
      *(.data) *(.data.*) ;
      _raml_end = . ;
   } > RAML

   .ramu : AT ( ADDR (.raml) + SIZEOF (.raml) )
   {  _rmau_start = . ;
      *(.data) *(.data.*) ;
      _ramu_end = . ;
   } > RAMU

   .ramz : AT ( ADDR (.ramu) + SIZEOF (.ramu) )
   {  _rmaz_start = . ;
      *(.data) *(.data.*) ;
      version.data
      _ramz_end = . ;
   } > RAMZ
}

additional patterns can be specified to allocate key input sections in a
specific memory region. Such control would not be achievable with a new
syntax ">RAML,RAMU,RAMZ" implementation.

It's not a very detailed "spec", but it's the strategy to date. (Barring
anything that I've forgotten.)

It would be interesting to hear how well that matches your use case, as
this is the time to wrangle any wrinkles, while maintaining existing
user flexibility.

Erik