From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) by sourceware.org (Postfix) with ESMTPS id 1A5F63858D33 for ; Wed, 7 Feb 2024 00:33:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1A5F63858D33 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 1A5F63858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::332 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707266029; cv=none; b=R4YZYcmRcs81N0LnDT8aI8xSevlSW4OCmvJUb4ekDM1NZCupYmZDg6D+lZgtt3MYBz5FjBZOeVgIyhhaEnf5kN5dGmHwzlO8LnoUFqiMK83UACYoaz2ZFjDC3y1Hfa02r9tds7rm46LobGHrMsqKA7ZqKZ+xTIjcv7tDYUIXXxY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707266029; c=relaxed/simple; bh=NwObYjcESeCm/TYaokagACdD2OfwrcHUWIwtICV4zq4=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=Zs1G81/GRHtqVoU/b7KERB85h3sWaNcxmOZjF1wFp5WEggc6yuqdCofZTuT79B0Ut6r6y2kvoGc1nGCU6Iif+OKB7QioHMO25/rXG3jQWoHCA+U+zIvVEP57iUq2TTJ26Ng1wniTTRTdrq/J74QMjwlfhHrJPaX5Fyg5efmzOYc= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-40ef9382752so28245e9.0 for ; Tue, 06 Feb 2024 16:33:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707266024; x=1707870824; 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=oLX0ayEEx/FExCzM7qg+LuTp/JC+iKfWqsvMRrKq/TA=; b=tsysyhovkdK/mV/Cx6xvUV4A02b35wrEyt/uuePPn09DKJPpYTADkmjGdC2IIOa3Ey v4rF+uC1JcNzWKVL9cJK+IZ7we1Rn+q1W6PyaR1CAaxcmkZi3TwrOX4hCgCCDBoY0U2Y Jkjq0rDYeWqXqlKYGuVgBExN8SYwxZOduhsokoUordN0DwmT9mj3/qv7A6rwzcnkD75P igBboT7EYElVVWiQaQTpq0iS7KRhvGaIt8o6eiz96zGJWn/EWRLZQChnEDBGF0FeUAAe mOvlBTiqzDFR9ZQ/uGkw8fiOKPuljw7QLd5KlS+iymrft91eOcO32QrsmaBF19ljEpAo p+6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707266024; x=1707870824; 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=oLX0ayEEx/FExCzM7qg+LuTp/JC+iKfWqsvMRrKq/TA=; b=qKNOhR1uh2/oCvGi6LboxQUT/+zkifs5KHQC9LfBoSk7VDw7AQI6avatGBdN4cpg3v po8UCoQuI0O9L6+/MWWrxEj7np9+x0DuJqXXBHtPLQMO/M8ZQozQgSBw5sR/i6CPHjmv mBbJxIl6astzHuaPloWcE6LsK96gJcAvZiz6KCh/EhcLDeMnUzfRefOl/ai8uLY3pmkZ IKjxZlz0tBBGzOGJ4jnadXFmku9xQ3P8qkKQiLgQWCduw/gk38SL7EONak8LYJjHkQbQ iHqgg7TnGPcB4Wis6pX1U0goCff/6bsquuNiIMvl0vcbuzZRH/KUXv/1SlU0Cka3oaXH /GSA== X-Gm-Message-State: AOJu0YwkdkIJNepF+xi6hTc8WVmgYtx3jDpiKSwuWCshVsqCZYY10xqa 40RniKUlxNz3G3n7Jle1AliLT4sBPQ5mvYe4cN7mWy1fZC1dp0KSLzmpPr6A8Acc8VO0btllVJe gxQ7+EWzIdwcT6QAWLfAfhh9ahp1tEoIztRwQ X-Google-Smtp-Source: AGHT+IGZDpTiGyVQqbwjgcjtPBSF5BV2JB1GfvOdBI8QHqidZUD9A1AAcGJiQxWrZBcpdoa6WNc8wITi0Dyb2hR0fIU= X-Received: by 2002:a05:600c:501f:b0:40f:feb1:a51 with SMTP id n31-20020a05600c501f00b0040ffeb10a51mr8851wmr.1.1707266024125; Tue, 06 Feb 2024 16:33:44 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Roland McGrath Date: Tue, 6 Feb 2024 16:33:30 -0800 Message-ID: Subject: Re: [RFC] ANY linker script syntax for non-contiguous regions To: Daniel Thornburgh Cc: binutils@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-18.8 required=5.0 tests=BAYES_00,DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,ENV_AND_HDR_SPF_MATCH,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: 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()` 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()` 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.)