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

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

On 24.07.19 11:18, Simon Richter wrote:
> Hi,
> 
> On Wed, Jul 24, 2019 at 08:28:05AM +0100, Nick Clifton wrote:
> 
> > If you do allow backtracking then the ordering of sections can change
> > from the current linker's specified behaviour (sections are linked in
> > input order unless a SORT keyword is used).  And so users will complain.
> > If you don't allow backtracking then there could be gaps in memory
> > regions which could have been used, and users will complain... :-)

In the years we have waited for a sufficient need to warrant
implementation, potential users have been rarer than hen's teeth¹. My
instinct is that anyone needing flowing will be grateful to have it, and
will accept both the proffered granularity, and freedom from the curse of
backtracking. The prior consensus has up to now been to respect FILL for
the trailing segment remnant, and that looks fine to me. (It is a darn
sight easier to implement too, I figure.)

That a given hole potentially grows by almost the granularity of the nearest
input section seems hardly troubling - and if it is, then it is up to the
user to reduce the size of the nearest input section, I submit.

But I figure that the casting vote probably goes to the implementer, who
has the imperative of a current and actual use case. :-)

> And if a section would fit after linker relaxation, but the new layout
> would make the relaxations invalid...

The previous run-up at this problem specified the flowing granularity to
be an input section. Flowing an input section across a hole has been
avoided, specifically to stay out of the clutches of such relocation
issues. (There's enough work there already, I think. :-)

Erik

¹ All right, there was one, admittedly, but it didn't lead to
  implementation.