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

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

As two prior posts of this content have failed to appear on-list,
apparently due to an auto-spamblock, we'll try again after invoking an
unblock, and waiting a bit.

On 07.03.17 11:06, Tejas Belagod wrote:
> On 03/03/17 10:27, Erik Christiansen wrote:
> > There would undoubtedly be some real effort involved in tweaking ld to
> > rebase input pattern "first match" on output section overflow - where a
> > subsequent match is available. Whether that would best be done as a
> > "second match" search when needed, or replacing "first match" with a
> > list of matches at the outset, remains to be seen. The difference
> > between theory and practice always looks smaller from this side.
> > 
> 
> I like the approach you've proposed. I admit it is more practical than
> extending the syntax for more regions. But, I see 2 disadvantages that are
> more cosmetic than anything else:
> 
> 1. Is the duplicity of patterns over multiple output section regions as
> expressive of the intent as using '> REGION1, REGION2,..., REGIONX'? Though
> you could argue that if the subsequent-match flowing feature is controlled
> by a command-line switch, the user knows what they're doing and the
> intention would be implicit.

Both flowing notations make the intent explicit in the linker script, I
think, but when adding inter-region flow, it is worthwhile considering
more than one use case. Requests for flowing around holes have appeared
on this list before, and flowing input sections according to a single
set of ordering patterns is the simplest case, without much flexibility.

Let us consider an embedded application where flowing of the bulk of
input sections is required, but some of them must remain together for
addressing reasons (e.g. pointer-relative reach, or page-zero addressing).
That requires differing input section sorting between output sections,
but is not possible when a single set of patterns is forced on all the
flow regions.

For such cases, and more complex ones where we might require another
group of input sections to be herded into e.g. the last region (it might
be slower bulk memory, best for low-use data, perhaps), it is essential
that the linker script be able to specify such sorting, optimally by the
existing scripting method of utilising an output section to contain the
sorting pattern subset for the associated memory region.

For the simple repetitive case, copy/paste is the slightest of burdens
which disappears instantly the moment the product requirements evolve
due to the hardware boffins or customer requirements necessitating
selective flowing. That is not the time to discover that we have
designed all flexibility out of the flowing implementation, I submit.
(Most especially when the flexibility comes at no cost beyond the pattern
rebasing for basic flowing.)

Yes, a command line switch for enabling flowing might be a useful
safeguard, as we have discussed.

> 2. If we have complex patterns matching input sections/filenames,
> duplicating it over multiple output sections statements might be prone to
> copy-paste errors. Keeping them consistent after changes means diligently
> replicating them everywhere - adds to maintenance overhead.

Hmmm ... the initial replication is mere copy/paste, but I take your
point about subsequent maintenance of the simple case. However, being
able to edit code/makefiles/scripts is a basic programmer prerequisite.
Muck up a makefile, and we discover the need for accuracy too.

Currently, we similarly flow by manually tweaking input section patterns
in output sections, so creating and keeping an eye on the patterns is
nothing new, really. 

Importantly, if any input sections need to be herded about, the
mechanism for it has not been designed out.

> 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.

I'm also intrigued whether you'd in the end be satisfied with a partial
flowing solution, covering only one use case, when less effort covers
a very broad diversity, using existing notation and usage. ;-)

Erik