From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id 383303858D38 for ; Mon, 12 Feb 2024 10:04:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 383303858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 383303858D38 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::631 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707732289; cv=none; b=xfWc+hjxT24AGhdQgOsz8M1Q/AkYbY9zPIrxlHUqJ+/92tt2tgrwEHqoBlblDLZbne39ureQmQg3uLrZo/xK0bGG5o1NzV4Tp4RF5McNjD87ySyNyzYEmCbBsAJ92AKQjV+yMU10H9TNkQIj+L02uks4Dc1n56BwTMkPirOgy3k= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707732289; c=relaxed/simple; bh=WSPZNBPYy3jrSi6bD3PjANSYvV1FubNabQ74CdUStyU=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=VBL7ne5DbuqDhEokBqCAQ+OjvYrvZX2tcTUYkefjbWdJYCdOfHD04vzw6xP04qBZzVGxMTo0a8K+dElg8daj+9ktwQfMt/yKWu9qJOpulQOpwcg70NLS4mJp3qZiLmyHRyRIqGtRPUcFH71zi0s9U9+SdgfeaZY7knBBUUA+u50= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-a2a17f3217aso383480366b.2 for ; Mon, 12 Feb 2024 02:04:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1707732286; x=1708337086; darn=sourceware.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=gmT2w917gRB9FtoyK82eW3vUrbSBabCp3DIjuK+e7vQ=; b=KqKYCwhd6GWu3boAjLo7UWLzIE9tOrHShda8su3GBSGsk7EBzfQVnRSJUc6AygXDCb UsnplF890vzm0r/3wsFAYgP60/+OA8qHpKEpppPNGrOY3hXed5UzD1Xqx/0aU2m49ql4 URCPiEI5AE/ax1EmgoCguHsHxcq6mVKWUooSLDhjP7Cb6IrT5o770xqt+3qqgl/TrZzc oMsg67h5ed03P9xYyure9j6t3iWbW6o4YAZy71FoNQCRA4bR7FDZPuEaJA3ZTi+9HPbL Y/rrNprrFl5HuqDRg+7467Ot5QqEPpNlDvdnFACCMZuO/6HN912FNVit7rTMop5HKLt2 8j8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707732286; x=1708337086; h=content-transfer-encoding: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=gmT2w917gRB9FtoyK82eW3vUrbSBabCp3DIjuK+e7vQ=; b=j4pG8jiGTmVq/0wIBS4U0ANwxpW5FIrJwsUOItx/L5L7JqIVKpGclT+dDTJUjJdKJy 8igCvsYvGPoPktQEaXLHQ7gU502lEnWr0kZzcMgaP162JrXSnTkWmDBWTCUTjCW48VdF qpth7L1cL2XYP795Bnmj/cA0scnZqbukWCzoAXu144Sgu/GYQXp7eabnWrbmBdl7StIw YUexBsGpFYkmZo0DSfMgUb/XoGcK8Dt3IlGXxZm8oYwXMixRc6kIteaLqu4CAZDYCwNc TzBqbxLgHGr0PWfvvTu+Op+pFE1SpDN1D1/P+UrWW/MUcFv7TILEHSDESKZzxymYm4va iC6g== X-Gm-Message-State: AOJu0Yxl9PoFMZTz7gjzoL1zhu1mj5EZM6EOJHhsulVNtPDJQk5eMzQf 174EdzSF2pqzXkhg81RP0/ovc10CbdS7N/J4QxyKbesddRbGfTXM3KfeWMt0dgrcRkEOt/8SAE6 61wlHMGB66UIsFph7tIgFUwcRrlZQhoxgl7Gdew== X-Google-Smtp-Source: AGHT+IEACukg9O1eV6pCBAiVNjeEB9PDlBDqxpny0aS/Ldu1cLxQ0prQ/mervQh0ewDyaI2bmPSRCQI/Smqm4KXso4I= X-Received: by 2002:a17:907:9858:b0:a3c:2146:a0be with SMTP id jj24-20020a170907985800b00a3c2146a0bemr4073900ejc.70.1707732285660; Mon, 12 Feb 2024 02:04:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Christophe Lyon Date: Mon, 12 Feb 2024 11:04:38 +0100 Message-ID: Subject: Re: [RFC] ANY linker script syntax for non-contiguous regions To: Fangrui Song Cc: Daniel Thornburgh , Roland McGrath , binutils@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: Hi! On Sat, 10 Feb 2024 at 07:33, Fangrui Song wrote: > > +Christophe > > On Wed, Feb 7, 2024 at 3:23=E2=80=AFPM Daniel Thornburgh wrote: > > > > One more tack on: maybe just CLASS instead of SECTION_CLASS for the nam= e... it's only legal within SECTIONS {}, and none of the other things withi= n 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 el= ements from that section could be placed there, and the only plausible mean= ing for multiple references to the same class would be to allow them to spi= ll. > >> > >> 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 l= ater, perhaps to avoid a broad wildcard needed for output sections that sho= uld 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 scri= pts. To spill a wildcard match inside an output section with strong orderin= g requirements, you would need to define classes for anything that precedes= it. > >> > >> Without spilling: > >> ``` > >> SECTIONS { > >> .foo { > >> *(.foo.first.*) > >> . =3D . < 0xc000 ? 0xc000 : .; /* or something similarly horribl= e */ > >> *(.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 secti= on 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 unintentio= nally 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 c= hanges to the linker script */ > >> SECTION_CLASS(foo_rest) > >> }>m2 > >> } > >> ``` > >> > >> Progressive enhancement of existing scripts is essential for this to b= e useful in practice. As far as I can see, since linker script semantics ar= e so imperative, that requires section classes to be nameable in the same p= lace as existing wildcards. That being said, as mentioned earlier, naming o= utside output sections also adds power, so it might be useful too, but it s= eems 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 i= nput > >>> section wildcards in the defining `SECTION_CLASS` clause, and then ev= ery > >>> reference has to always just draw in order from that sorted list. > >> > >> > >> I would expect SECTION_CLASS uses in output sections to be referential= ly transparent with the exception of the packing behavior and the ordering = of section "consumption". They should broadly behave as if the named wildca= rds had actually appeared in order in the corresponding location; that shou= ld allow providing a set of allowed and disallowed SORT_x family specificat= ions 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 wa= s intended. > >> Maybe I can provide some background about the discussions that took place on this list when I implemented --enable-non-contiguous-regions My first proposal of implementation was: https://sourceware.org/legacy-ml/binutils/2019-11/msg00402.html, which led to some discussions (sorry the list archives are not easy to browse across months, discussions continue until March 2020 when I finally committed the patch) This was a result of my follow-up in June 2019 (https://sourceware.org/legacy-ml/binutils/2019-06/msg00254.html) to a discussion originally started in Feb 2017: https://sourceware.org/legacy-ml/binutils/2017-02/msg00250.html Hopefully these discussions can give you more background. IMO, a big advantage of the global flag is that it makes the implementation not too intrusive, and it's easier to understand for end-users. In my experience, many users have trouble understanding how to write a linker script, so having multiple keywords with "subtle" differences or changes in behaviour depending on the context is confusing. Christophe > >> -- > >> > >> Daniel Thornburgh | dthorn@google.com > >> > > > > > > -- > > > > Daniel Thornburgh | dthorn@google.com > >