From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) by sourceware.org (Postfix) with ESMTPS id 9EDE53858C42 for ; Fri, 26 Apr 2024 04:17:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9EDE53858C42 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9EDE53858C42 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::52d ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714105078; cv=none; b=kZccShyLc1f1Y89TDCzybmJXDLNwynude7f2aRTt7MtHEiJxSjJPs385b8AoOiXbfXb0PahvyglHoZ7piuUNw9qxs2IB2HUlzvWMjYC6nUKtkPYY642oJu8LxUKRErFX06+Dn3v/gULaR5p0PGAMorek22WmN5n6Jzsvxi/u4dQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714105078; c=relaxed/simple; bh=x0v3dLoSRLOEzlaGlHGsGJh+VlbHWW7kiZ+wfAwLymE=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=W6VQ8/gtpujNjaal1qYXWQ4pDUA9Uwnqc/r+ZzIxqXfH7GE6RHrNS1AAXwIkullM4EP5b380hTBhh46B1rHkgR5g7K3ZgPMKR1iJ0fug3WF8z1LiybQ/hIa4YcF4fTy5JB8+jC3/wZkmo0AVXC7WkwpXR0i9Mg4Oz82Ch15/rHA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pg1-x52d.google.com with SMTP id 41be03b00d2f7-5ce2aada130so1215372a12.1 for ; Thu, 25 Apr 2024 21:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714105074; x=1714709874; darn=sourceware.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=qh+xl32BNMj9aB5j74s56GFdbvCnTgTeUchzUeRY4vg=; b=DIL2eH3zj5t47R1WTnld1YjOEs+9NHKrpAAP2VBLe2oVM06tvZx2qyH5YymRKfRVrp n6W/NtVP8PnTMb8c5n8HH8nL+o4WGcnyFB/2VFtVEuGeTlOvKlwFHp0ubE/mQJdRiLdF cyxsGZTEyUw9ywUQ5jAsFINOPnehA0MID0esAsEjlcP0oHOTt+6+dfYVoDakxU5RZ0xW MUBvGPR/5CDDNJBSB9StNgaQ4LAKn/Xu2YsQGx2dy/ZlJ+iFCq5IeBzzT3S05erooT0L dTfhfy12TqVcQQuR0kez8q10lG7DT5j3jVEkk2dVMIR7BCNSe3+3RLe63YOoZrr1rRZo YYJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714105074; x=1714709874; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=qh+xl32BNMj9aB5j74s56GFdbvCnTgTeUchzUeRY4vg=; b=YZJva4e/8z7nl9YkjT4xd0rzomnz7p5Yrq3fn3Tg+Q7WO8/CubFqUps+6dwBV+wMFL sHAyKs8FuXD/9rUN+uurfU9eEqvvXgVsFttD70IRepMNxsDhWlhE10reuTx9Gdm3Qaah m+keG9oJlqLdn8iIhERlAKcWnDv9al/mmNN3FaGO6WVi30F0WL3EKIVCl1GfnWYA2wQB ZtAA9hDuoQAfgxugXoel7kS/dtwGZkuRPtHDI49+WT7138p50puhbybk+lKgUi4rlpVr JlrCfU3QdzWZ5eipApqLP6Y1YOOCNt9jpTQ9sDHERw1Ki6mQX5lRC4UTH7Hczrfng8Mv sFRA== X-Forwarded-Encrypted: i=1; AJvYcCWG6CP4VYG9BEuiWY/brIp8L+4Yhb5amnb5nc+xO9N9NiwPxOMsnfFvCLjeSGtioO2FK4Ldze5kNsfIsAtSqlWokJmNTz47EA== X-Gm-Message-State: AOJu0YwtQA+ZGI+BVzi4P3t3xivVJN6NbxqXFhBdRwd7/UavtboyZYiP pkmf8gJw2Wi9QAc/PFrwplaReJF9aeFJZhD+OiKLwI/QfGgrfOzAlVxK8g== X-Google-Smtp-Source: AGHT+IFfSCzfSQRM/QRD8lGUyn8ujGwfEH8Wzg5z2T6kvYnWN2m2VK6LPIiI5NnDB2+S5sdmA8qMnQ== X-Received: by 2002:a05:6a20:5b12:b0:1ad:3d93:b71e with SMTP id kl18-20020a056a205b1200b001ad3d93b71emr1528874pzb.59.1714105074184; Thu, 25 Apr 2024 21:17:54 -0700 (PDT) Received: from squeak.grove.modra.org ([2406:3400:51d:8cc0:ccad:cc8:6082:5db7]) by smtp.gmail.com with ESMTPSA id q9-20020a170902dac900b001eb07ee30e4sm332319plx.2.2024.04.25.21.17.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Apr 2024 21:17:53 -0700 (PDT) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 47F8D114021E; Fri, 26 Apr 2024 13:47:51 +0930 (ACST) Date: Fri, 26 Apr 2024 13:47:51 +0930 From: Alan Modra To: Nick Clifton Cc: hjl.tools@gmail.com, binutils@sourceware.org, siddhesh@redhat.com Subject: Re: RFC: ld: Add --text-section-ordering-file (version 2) Message-ID: References: <87edat7g1e.fsf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87edat7g1e.fsf@redhat.com> X-Spam-Status: No, score=-3025.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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: On Thu, Apr 25, 2024 at 02:01:01PM +0100, Nick Clifton wrote: > Hi Guys, > > Attached is a patch to add a --section-ordering-file option to the BFD > linker. It is based upon H.J.'s original patch, but extended so that > it will work with multiple output sections. > > There are a couple of points that I feel I should highlight: > > * The option only works in conjunction with a modified linker script. > > In particular the script must have: "INCLUDE section-ordering-file" > statements in it, wherever it wants section ordering to be allowed. > This statement can appear multiple times in a linker script, > although it would not make sense to have it appear more than once in > any given output section. Here is an example: > > SECTIONS > { > .text : { > INCLUDE section-ordering-file > *(.text) > } > .data : { > INCLUDE section-ordering-file > *(.data) > } > } > > * H.J's original version allowed for linker script like > "filename(section)" syntax to be used to name sections, eg: > "*(.text.*)", as well as a simpler "section name regexp", eg > ".text.*", to be used. This version only supports the latter > format. > > In addition H.J.'s syntax allowed for abbreviated section names to > match. So ".t*t" would match any section starting with ".t" and > ending with "t" and would put it into the .text section. In this > version however the output section is selected based upon matching > the fixed part at the start of the pattern with the output section. > So ".t*t" would only work if the output section was called ".t". > > To help compensate for this, and to allow arbitrary input sections > to be mapped to specific output sections, the output section name > can be provided as if it were a filename. So .foo(.bar) would map > all sections called .bar to the output section .foo, but only if the > linker script has an output section called .foo, and only if that > output section declaration includes a INCLUDE section-ordering-file > statement. > > Perhaps an example will make things clearer. If the above linker > script is used and the section ordering file contains: > > # A comment - this will be ignored. > .text.hot .text.cold .text.warm > .data.big > .data(.bar) > .text.foo* > .ignore(.me) > > This is roughly equivalent to a linker script that looks like this: > > SECTIONS > { > .text : { > *(.text.hot) > *(.text.cold) > *(.text.warm) > *(.text.foo*) > *(.text) > } > .data : { > *(.data.big) > *(.bar) > *(.data) > } > } > > Note - the linker will not warn about entries in the section > ordering file that do not match an output section name. So in the > above example the ".ignore(.me)" entry will not generate a warning > about it not being used. > > Thoughts, comments, etc ? This seems really clunky to me. How about a script that augments the default script, but looks very similar to other scripts, ie. with a SECTIONS clause? To take your example, use a script like: SECTIONS { .text : { *(.text.hot) *(.text.cold) *(.text.warm) *(.text.foo*) } .data : { *(.data.big) *(.bar) } } Then arrange to insert the contents of each output section statement in this script at the start of corresponding output section statement in the default script. -- Alan Modra Australia Development Lab, IBM