[RFC] ANY linker script syntax for non-contiguous regions
Roland McGrath
mcgrathr@google.com
Wed Feb 7 00:33:30 GMT 2024
This sounds like it essentially creates a two-phase system for assigning
input sections to output sections. As such, IMHO it would be cleaner not
to combine the two phases in a single syntax. That is, your proposal seems
to have two uses of the new syntax, both inside an output section clause:
the "defining" use matches a subset of sections being selected for the
output section whose clause it's embedded in; the "referring" uses then
refer to the unassigned remainder of that subset in a later output section
clause. What seems clearer to me is to have a different kind of clause
that's not an output section but only defines a new subset of input
sections for later use. Perhaps:
```
SECTIONS {
/* Traditional output section clause: */
.output1 { *(.input1) }
/* New syntax that is not an output section clause: */
SECTION_CLASS(class1) { *(.input2) }
/* Output section clause referring to SECTION_CLASS: */
.output2 {
*(.input3) /* normal section wildcard */
SECTION_CLASS(class1) /* reference to previously defined class */
*(.input4) /* normal section wildcard */
}
.output3 {
SECTION_CLASS(class1) /* reference to remainder of class not in .output2 */
}
.output4 {
/* reference to remainder not in .output[23], sorting applied to them */
SORT_BY_NAME(SECTION_CLASS(class1))
}
/* This cannot match anything that went into a SECTION_CLASS and orphans
placement does not apply to them so it's an error if any
SECTION_CLASS-matched input section has not been assigned to a
previous output section. */
.output5 { *(*) }
}
```
The idea is that `SECTION_CLASS(<class name>)` works like an output section
clause in that position as far as its input section wildcards matching and
"consuming" input sections that are unassigned at that point in the script.
(Nothing else but input section wildcards would be allowed inside the
braces of a `SECTION_CLASS` clause.) The sections it has matched are
"consumed" such that they cannot be matched by any normal input section
wildcard later in the script. They are also excluded from orphans logic.
The only way these input sections can now be placed is by having
`SECTION_CLASS(<class name>)` appear in one or more output section clauses.
That causes as many of those input sections to be placed in that output
section as can fit. Any that don't fit remain in that SECTION_CLASS's list
of unassigned sections to be drawn from by another `SECTION_CLASS` input
clause.
Where they do appear, they can appear inside the SORT_* to have that
sorting applied to the subset. I'm not sure it's actually meaningful to
select a subset and then sort within that subset, so perhaps it would be
better to only support the SORT_* modifiers in the usual way on the input
section wildcards in the defining `SECTION_CLASS` clause, and then every
reference has to always just draw in order from that sorted list.
Note that this implicitly provides the option to insert:
```
SECTION_CLASS(orphans) { *(*) }
```
at the end of the whole SECTIONS clause. This means that all unassigned
sections go into the `orphans` class. Since no output section clause
consumes from `SECTION_CLASS(orphans)`, then it's an error if the class is
nonempty. This provides a way for a linker script to rule out any unwanted
orphans placement, which is challenging today. (It's probably possible
with SHF_ALLOC flags matching and ASSERT, but quite picayune.)
More information about the Binutils
mailing list