From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) by sourceware.org (Postfix) with ESMTPS id C371A3858D33 for ; Tue, 6 Feb 2024 23:58:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C371A3858D33 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 C371A3858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::f2e ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707263933; cv=none; b=WXzt3rlv27v0IQ63G5fWZbJunM8bgTIohuai5rXDZ0mQa9G2FMa7kurNKjpdLfechxHlD77PDw6BHITrNMUbPP6U40vC8AxRiPSDdUnIHBS05yrXWwZ3RWlOtuDJ7h7U4SxNQ6ydu9Pt23v/3K2E9+0ZapljeX96/eO80n8uulw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707263933; c=relaxed/simple; bh=Nvjp+c9JD6QBcVfe4hNhpeAfyMM4X8WOG/Z6liBbyBg=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=f5hZq+cG33jyCkqObWrTpmE61H2SJwLKzLM9EB8syugl/7hHjIg2RtBHOdPWcMuFCdxGDd94n9UJvtzNg3hywHOwQc82RBJLvLTlZ6FK9yNFcIWjITlRMiZOahKhb62DgkW6/Eq4hnC0M2tj6/uUCSnFMYYHc9//qm21c2wB2Cs= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-qv1-xf2e.google.com with SMTP id 6a1803df08f44-68c444f9272so288416d6.3 for ; Tue, 06 Feb 2024 15:58:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707263931; x=1707868731; darn=sourceware.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=rQNtY5KK/YTz5YsFCa/5WDgEX/ktopZrZ2gpSRhg/1A=; b=AuaJ43QCAGVq2ILnWdZKuEU+Uv57JZpY2JMejBf8TE1GpauoYE/WwBLja5zXiU07o0 +DRWO6qlcK7D4uz5B+UHsEH/NxWknO3CTE5j/rZI6C9AupE226eGTsPia6D7F+g3rjsE GnVwtsp+B9AWENPsybtxf6S249KTzHJwDRToYa7bo0PjRSXElhEe0QBywaO2CbuPG0jZ rhJs2Id2ERcGQ8fpeZmIRKuX/VNKmmfWHfDt+gIwnWA5t6P0jSEk8SMt798QlfnAhI3e Cc4bxTIc/lKfbstyshVZVmtq2EJl1g8Q/4r1+8tpwb+z3TAuVsB11lVBilJ7+L88l2pp AMBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707263931; x=1707868731; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=rQNtY5KK/YTz5YsFCa/5WDgEX/ktopZrZ2gpSRhg/1A=; b=LPy2xM4XneX8WW3wbYG665ehAvGHGjmmcqa2d65ZsQ0edGHz4zeF/VGOHlYfoqkrlf 0enknQ3rK/PT+PvshJzJdipumsUOKSiC7ionRd/62ZZTdeQp8kaUwYyNqzBCldd8xiu9 zgh/bYMOofXvLaMI6QKYU4bSKFz8MhA2aAHMbVPnwz9JDEJq4Sy4+XTd1XtkFWhnrkS6 KWRlJJNIi5R/KJPwmZfIXF13MOKwcjEmHHXY5IQC+JcSrb63y+9zlJu1O1k+uu+Mb5S4 z73uL9d+g4VSRtoRvvd9RlcBSKl3l3g04Fx7cRmSd8HOwS08Wj9fYaoYLl6g/JlLIDL/ rnkQ== X-Gm-Message-State: AOJu0YxxBjO/eGSV2Ga7nBxCiFaisUoLz/Jr4I2uw1CofVb/v0e/31zW vqL8SvyKq9IlC+kHhIrwArdwWQ79E2+SZwHjRRYSHNXJ3r4vE9VMGCVCBHoxpAgqhPKy0peNOGi YU/ILFKIxW7z3v8meOEo10JE2yWpvQby/A6Nv3tzxjVogUzzIgoRk X-Google-Smtp-Source: AGHT+IFzYfl2N4eCC8/SBrzH3hN+LIRRlXMKYydh4SPu4o0x9JaqfuTahtHbgpiLgIUjTMYrSsgTx2/2iEYjYsJgl9M= X-Received: by 2002:a05:6214:4113:b0:68c:92ea:c5ed with SMTP id kc19-20020a056214411300b0068c92eac5edmr5241298qvb.34.1707263930886; Tue, 06 Feb 2024 15:58:50 -0800 (PST) MIME-Version: 1.0 From: Daniel Thornburgh Date: Tue, 6 Feb 2024 15:58:39 -0800 Message-ID: Subject: [RFC] ANY linker script syntax for non-contiguous regions To: binutils@sourceware.org Content-Type: multipart/alternative; boundary="00000000000023b23a0610bf5cc9" X-Spam-Status: No, score=-17.3 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: --00000000000023b23a0610bf5cc9 Content-Type: text/plain; charset="UTF-8" I've been working to add a feature for section packing akin to LD's `--enable-non-contiguous-regions` to LLD. Discussing this[1] revealed a desire to have an explicit syntax in the linker script, rather than having a flag globally modify the behavior of wildcard matching and address layout. I wanted to pop my head in here before implementing anything too extensively with the hope of arriving at something that could work across linkers. I'm currently thinking of something like the existing `SORT_BY_xxx` modifiers: `ANY( )`. This would match input sections identically as normal, but it would record the set of matched sections as associated with the given tag. Then, any further instances of `ANY()` without any wildcard patterns would provide locations that the tagged sections could spill to, as if by a subsequent `enable-non-contiguous-regions` match. `ANY` refers to the possibility that any of the tagged sections that fit may appear at that location. (The name feels weak to me; it comes from a vague reference to an armlink feature with wildly different semantics. Open for suggestions.) Using tags avoids introducing a new semantics for wildcard matching; a section would still always match exactly one wildcard. Accordingly, it would preserve the ability to use broad wildcards to refer to anything not yet matched by earlier more specific ones. This in turn should make porting easier, since linker scripts may be written assuming this. By contrast, `--enable-non-contigous-regions` makes broad wildcards potential spill locations for earlier matches, which may not have been intended. [1] https://discourse.llvm.org/t/rfc-lld-enable-non-contiguous-regions/76513 -- Daniel Thornburgh | dthorn@google.com --00000000000023b23a0610bf5cc9--