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

[Tejas Belagod]

On 09/03/17 12:06, Erik Christiansen wrote:
> 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
>

Hi,

Just wanted to give you the latest on this. Unfortunately, I have suspended 
working on this feature for the foreseeable future owing to a shift in 
priorities. Will update if there is a change in circumstances.

Thanks,
Tejas.