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

[Erik Christiansen <dvalin@internode.on.net>]

Given that atomicity of flow around holes is to be input sections, there
may be a simpler equivalent to the proposed new syntax:

On 22.02.17 15:28, Thomas Preudhomme wrote:
> MEMORY
> 
> {
>   RAML (rwx) : ORIGIN = 0x1FFF0000, LENGTH = 0x00010000
>   RAMU (rwx) : ORIGIN = 0x20000000, LENGTH = 0x00040000
>   RAMZ (rwx) : ORIGIN = 0x20040000, LENGTH = 0x00040000	
> }
> 
> SECTIONS
> {
>   .text 0x1000 : { *(.text) _etext = . ; }
>   .mdata  :
>   AT ( ADDR (.text) + SIZEOF (.text) )
>   { _data = . ; *(.data) *(.data.*); _edata = . ; } > RAML, RAMU, RAMZ
> }

AIUI, that syntax proposal is motivated by the effect of this ld info
documentation "If a file name matches more than one wildcard pattern, or
if a file name appears explicitly and is also matched by a wildcard
pattern, the linker will use the first match in the linker script." I.e.
instead of seeking subsequent matching wildcard patterns when needed, ld
generates an overflow error on .raml, given this hole dodger, using
existing syntax:

   .raml : AT ( ADDR (.text) + SIZEOF (.text) )
   {  _rmal_start = . ;
      *(.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.*) ;
      _ramz_end = . ;
   } > RAMZ

I am led to wonder if it might not be less work to merely tweak ld to
look for subsequent matching wildcard patterns in following output
sections before issuing a region overflow error. I.e. ld merely
redefines "first match" if a subsequent one is available when needed.
That seems less intervention than adding new syntax to the script
interpreter, and then grafting on the new capability.

The overflowing input section needs to remain in the input queue during
the output section bump, to complete its "go-around" on failed landing
approach.

One significant advantage of this approach is that part of the
established practice, i.e. constraining certain input sections to low,
middle, or high RAM regions, remains both straightforward and explicit.
If multiple output sections are directed to a region, even finer
constraint is possible _simultaneous_ with inter-region flowing on
overflow. On the other hand, what would happen if multiple "> RAML,
RAMU, RAMZ" were aimed at these regions in an attempt to enforce a
paging or proximity constraint while flowing?

Utilising the existing syntax, which we've used for many years with
explicit input section patterns, empowered by a small ld intelligence
increment, would seem to manage the task with less effort and more
control. How does that fare as a modest variation on skinning the cat?

Erik