From: Daniel Thornburgh <dthorn@google.com>
To: Roland McGrath <mcgrathr@google.com>
Cc: binutils@sourceware.org
Subject: Re: [RFC] ANY linker script syntax for non-contiguous regions
Date: Wed, 7 Feb 2024 15:23:25 -0800 [thread overview]
Message-ID: <CAEdiOyfynde_nO5arUBD+gb+FOCYn4M=oLpz-m7VsUUHFF5FHA@mail.gmail.com> (raw)
In-Reply-To: <CAEdiOyfVYNt8Sq+GGixNek-XMPZaOccx+YSd7QO7eeZy=EnPig@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4630 bytes --]
One more tack on: maybe just CLASS instead of SECTION_CLASS for the name...
it's only legal within SECTIONS {}, and none of the other things within
contain the word SECTION.
On Wed, Feb 7, 2024 at 2:36 PM Daniel Thornburgh <dthorn@google.com> wrote:
> This is interesting; I hadn't thought of breaking out tagging into its own
> construct. I do like the name SECTION_CLASS; it makes it clear that
> elements from that section could be placed there, and the only plausible
> meaning for multiple references to the same class would be to allow them to
> spill.
>
> This also slightly increases the power of regular matching, since you
> could catch a group of sections earlier in a linker script and place them
> later, perhaps to avoid a broad wildcard needed for output sections that
> should appear earlier in a memory region.
>
> E.g.
> ```
> SECTIONS {
> SECTION_CLASS(specific) { *(.specific) }
> .first_output { *(*) } >m1
> .second_output { SECTION_CLASS(specific) } >m1
> }
> ```
>
> On the down side, it would make it harder to port existing linker scripts.
> To spill a wildcard match inside an output section with strong ordering
> requirements, you would need to define classes for anything that precedes
> it.
>
> Without spilling:
> ```
> SECTIONS {
> .foo {
> *(.foo.first.*)
> . = . < 0xc000 ? 0xc000 : .; /* or something similarly horrible */
> *(.foo.second.*)
>
> /* Excludes .foo.first.* and .foo.second.* by virtue of ordering */
> *(.foo.*)
> }>m1
> }
> ```
>
> With spilling:
> ```SECTIONS {
> /* A whole collection now needs to be broken out of the output section
> to preserve its semantics */
> SECTION_CLASS(foo_first) { *(.foo.first.*) }
> SECTION_CLASS(foo_second) { *(.foo.second.*) }
> /* If only this section class were defined, then it would
> unintentionally capture .foo.first and .foo.second */
> SECTION_CLASS(foo_rest) { *(.foo.*) }
>
> .foo {
> SECTION_CLASS(foo_first)
> . = . < 0xc000 ? 0xc000 : .;
> SECTION_CLASS(foo_second)
> SECTION_CLASS(foo_rest)
> }>m1
> .foo_alt {
> /* foo_rest is the only desirable spill, but it forces sweeping
> changes to the linker script */
> SECTION_CLASS(foo_rest)
> }>m2
> }
> ```
>
> Progressive enhancement of existing scripts is essential for this to be
> useful in practice. As far as I can see, since linker script semantics are
> so imperative, that requires section classes to be nameable in the same
> place as existing wildcards. That being said, as mentioned earlier, naming
> outside output sections also adds power, so it might be useful too, but it
> seems like it would need to be judged on merit of the extra power added.
>
> On Tue, Feb 6, 2024 at 4:33 PM Roland McGrath <mcgrathr@google.com> wrote:
>
>> ```
>> SECTIONS {
>
>
>
> /* 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 */
>> }
>> .output4 {
>> /* reference to remainder not in .output[23], sorting applied to them
>> */
>> SORT_BY_NAME(SECTION_CLASS(class1))
>> }
>> }
>> ```
>>
> 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.
>>
>
> I would expect SECTION_CLASS uses in output sections to be referentially
> transparent with the exception of the packing behavior and the ordering of
> section "consumption". They should broadly behave as if the named wildcards
> had actually appeared in order in the corresponding location; that should
> allow providing a set of allowed and disallowed SORT_x family
> specifications to match the current behavior. That would support using
> SECTION_CLASS to break out an existing wildcard to run it earlier, since it
> would provide some assurance that this wouldn't change the behavior beyond
> that which was intended.
>
> --
>
> Daniel Thornburgh | dthorn@google.com
>
>
--
Daniel Thornburgh | dthorn@google.com
next prev parent reply other threads:[~2024-02-07 23:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-06 23:58 Daniel Thornburgh
2024-02-07 0:33 ` Roland McGrath
2024-02-07 22:36 ` Daniel Thornburgh
2024-02-07 23:23 ` Daniel Thornburgh [this message]
2024-02-10 6:33 ` Fangrui Song
[not found] ` <DS7PR12MB5765A6AA68F691E3A9641AABCB4A2@DS7PR12MB5765.namprd12.prod.outlook.com>
2024-02-12 10:04 ` Christophe Lyon
2024-05-01 5:07 ` Fangrui Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAEdiOyfynde_nO5arUBD+gb+FOCYn4M=oLpz-m7VsUUHFF5FHA@mail.gmail.com' \
--to=dthorn@google.com \
--cc=binutils@sourceware.org \
--cc=mcgrathr@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).