From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) by sourceware.org (Postfix) with ESMTPS id 237F43858C5F for ; Wed, 7 Feb 2024 23:23:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 237F43858C5F Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=google.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 237F43858C5F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::f2f ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707348221; cv=none; b=g/ugQOz91sluss79f8Xxr4YI4iEr3Di5Lt5vHMiQ8IeSUcuI1eFDVR958zrri456VSF8L8Iq0tuEWXhrOzPkWKm3aT1z1r1kFMn4anPhq16pNYu1Q/uxwGd+MgGG4e8AvLiU/tq6Ejjm6bh6BDP/7TBE0wIZ55e3VKr9sObguTo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707348221; c=relaxed/simple; bh=dCr73oUTZ9FphUgj+4Ukx7tksI8WLPMPXiRmaV1H4pc=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=qreoZcaTMHG+ZhtLK6X1D10BrXWT6gkVdWlcZpIEV5g4HI2zmQnKLytIxqMYXlk1cedn3Cwast0rDui0FJknv2FyNTH8v1VGot94d2ZS4j03aXtkBpEFedGhAEbsEslEjFP+CCg/IObdgWvoREcH5ARIzaqORFjCTK+pii1SBEg= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-qv1-xf2f.google.com with SMTP id 6a1803df08f44-6818a9fe3d4so6655306d6.0 for ; Wed, 07 Feb 2024 15:23:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707348217; x=1707953017; darn=sourceware.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=C2aasDDrZ/q74wtEtlXzUpGWuvcdHGXBLDrvS5eMFfk=; b=LfRhhgWo2BPPlSIDyw2xXvO9d9UI627mDQmu2pCpjJ7n1cIBjDdSsUug1+KxHKQvDM Q8UynOoODt7mLj7+kSdkt9KBDWV+A2EurDo9XQvULrE2/CVkPvhWSNUrADBFTRQRl5cP 0fcBeASVqabM2SPs2zeEZK7jy95DPhfPhjUSt6weHjy3Pyy63uAe9x2VoaWJv4ByUjNt 9S/oMZ+f6BsP9KhprYAFn9iL81hgYtGJfD6hRtaiGGEtuBw3hA8hXKfpYGi8xSBdCVJJ /lFPFLfdHACLJkVswH+KH8Z5OvTTv8hyVvnn+EGRUTIR3w0ctmfz0cXrchOE6dr8tkhg PKHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707348217; x=1707953017; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=C2aasDDrZ/q74wtEtlXzUpGWuvcdHGXBLDrvS5eMFfk=; b=PinyWi9u2PlT4ITcNBdUxONtYvAu0ArD1l74JMu9vaS3hOv6QO2Kz6D77uq/iMAXcG pbWt+Zz6G4IEpDW9FUry3TB7ORNKigql4Q42ymgMsZDnBx6FMHzgkHSOMJwKsHG5shoO XVfffd+PkPZFhS0Y06qinUsI0XcVFdw2GrTmxcVwPS6KxouSRjtd/ca178nZssIToZQg W9N6cdqiWuEfw2w00rUZ9KAahLiuZ+oTEmGJp9sNDf1GdDiOj964YWmVF5j3n1Ztjnl9 S8aJakT340eml7706cI4CD8ThhYftmPSjVIrUxuEwr3t/ssEaIrxv2lIVQWp+QfZgUN6 vcGA== X-Gm-Message-State: AOJu0YztPGkRv2CbiYzusDh7y+DQYStyN6ZpUTmgZmUV4xyIlptWj51o /9FfRbZpOPQVOKtkQMt4X9O6mswEEsP/0vVla7LWtv0Q2rGOTlOORyj6gxF8L5TZlqb+ExUDp41 5xwzDZVrm74eOooPmuLT5vKwn9qVpf4oF/l2Dg3jHlRrh8Z9PsA== X-Google-Smtp-Source: AGHT+IFdyBbBbGtiJiWvQ5Fv5jM5QU95SIJYbQ1j3GiRBXKvZp4qWXOFZb46p6v4uF+gLXTnmCzvWLAwP8LGeLt2B34= X-Received: by 2002:a0c:db01:0:b0:68c:4dea:1843 with SMTP id d1-20020a0cdb01000000b0068c4dea1843mr6686807qvk.26.1707348217223; Wed, 07 Feb 2024 15:23:37 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Thornburgh Date: Wed, 7 Feb 2024 15:23:25 -0800 Message-ID: Subject: Re: [RFC] ANY linker script syntax for non-contiguous regions To: Roland McGrath Cc: binutils@sourceware.org Content-Type: multipart/alternative; boundary="000000000000ff33420610d2fbe5" X-Spam-Status: No, score=-17.1 required=5.0 tests=BAYES_00,DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,ENV_AND_HDR_SPF_MATCH,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000ff33420610d2fbe5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Daniel Thornburgh 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.*) > . =3D . < 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) > . =3D . < 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=E2=80=AFPM Roland McGrath 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 wildcar= ds > 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 > > --=20 Daniel Thornburgh | dthorn@google.com --000000000000ff33420610d2fbe5--