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

[Christophe Lyon <christophe dot lyon at linaro dot org>]

On Tue, 2 Jul 2019 at 08:49, Erik Christiansen <dvalin@internode.on.net> wrote:
>
> 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.
>

Hi,

Sorry for the delay.

Thanks very much for this updated summary.

I checked with other internal users, and it seems it would be OK for
our use case.

I think I will have a look at implementing it, but not immediately
because of holidays.
I hope it's not too difficult :-)

What do maintainers think about this? Would it be acceptable?

Thanks,

Christophe


> Erik