From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-f179.google.com (mail-yw1-f179.google.com [209.85.128.179]) by sourceware.org (Postfix) with ESMTPS id 003073858C42 for ; Fri, 26 Apr 2024 17:04:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 003073858C42 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maskray.me Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 003073858C42 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.128.179 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714151065; cv=none; b=YXP8IywB0VWboPPDOXPuKZFQUpJLinjv/XSKLkQ7vLp8Q3hIGQnecCwFK0gfHgP6gR1teL8CDucNpi3NA5MLXF03UWNfJIQ+S8dWJp8zoEx/70xH1y9IB/potz+O0AKowpZiQZkhBmEKKeM7npGFfWDM1+Z1i8ZN3zmHFe3NlVI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714151065; c=relaxed/simple; bh=0JZ7ydRTLoVaMtKpggA+zJ3Ak7+JfeGks6kXlhDrsf0=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=nYSbDrjZk1ai0zUjwKuw1dlXy5bHi5lUEacAedy8W7ivA1Q8chyW4yirt1r097/F8FbH9RtnwCYrgk2toy60fdHSvzhslMCLnZlN5vJpNZwIlBQxll/I7cpJPbE6wguBHRrEiEMKStlWAkP+chpTUnNgSNV+fCwXmM1INzLuzck= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-yw1-f179.google.com with SMTP id 00721157ae682-61804067da0so22717367b3.0 for ; Fri, 26 Apr 2024 10:04:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714151054; x=1714755854; h=in-reply-to:content-transfer-encoding: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=uS49vgLKrjylV8HUyNsAWnIMYk04VxFSuKx+OTCIFYE=; b=hJwGo0fxg+IqwmPiJ9M8O+sLquI/IwxJXGZIBRnxUPZsbrJ8Cbxuzd8IUHvXdL3Rwx OyS/+xDZmSkMN0IOn/HAo0DJGU2nuhtsMoUq9k5HSqvsWWVm2iOxX1SJeVioLY3pEqid dLCLkyHkfhGO6JzfXRGXxsSZPze7g3jHzqm9VgPueSO42ZLyObTGmqhhsU4CZevLnFuY ovv9cUU86CMV5Y3CLMqm2igMs/6iBF399o7seaSNxC5W4PcwB78hiPay1j8MwTHlwXfF XTcYqXsobiGKbLLtcsqXCEgOLNQ93eEjPCK1X44siKnVWU8AddTFo+EeVans+J9wwqMU pNhA== X-Forwarded-Encrypted: i=1; AJvYcCXCFPh+8+LBTsscntQDS6EQGYLXHrvJp+eqKAcpHspdB1ThNyZhJ1rHU/GBHwP75ZqmE/oZ8Gd4rpWGwS3n2v1MyTeBCWr6HA== X-Gm-Message-State: AOJu0YxwVwrpZNlebrR20YdxlemfEX9g7ir40EQZHXMNJSUXhdwr1M4x fAF7UKC++VnqVpj5e3WGC9zwLHnOb4yAwyHU0MgxcPtVq0qpNao6 X-Google-Smtp-Source: AGHT+IGJw12ES4Bs6l0g5IKHIRDG4oyxrNFSfIYlRLmIjOjxSjLbMx1juzAZPizoAbePI4Ac/iYrww== X-Received: by 2002:a05:690c:600c:b0:61a:dc8d:25f8 with SMTP id hf12-20020a05690c600c00b0061adc8d25f8mr374637ywb.39.1714151054347; Fri, 26 Apr 2024 10:04:14 -0700 (PDT) Received: from localhost ([2600:1700:5b70:4260:e440:e80c:9bdd:2dbf]) by smtp.gmail.com with ESMTPSA id o19-20020a0dcc13000000b00617e3c07229sm4101583ywd.20.2024.04.26.10.04.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Apr 2024 10:04:13 -0700 (PDT) Date: Fri, 26 Apr 2024 10:04:13 -0700 From: Fangrui Song To: Nick Clifton Cc: "H.J. Lu" , Binutils , Michael Matz Subject: Re: RFC: syntax for a section ordering file Message-ID: <20240426170413.c6jgjlfnvyvaavub@google.com> References: <3f373229-b7cf-4229-9591-922838577652@redhat.com> <20240426030103.g62e3r7heuavejzp@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no 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 2024-04-26, Nick Clifton wrote: >Hi Fangrui, > >>* Apple ld -order_file. lld's MachO port ld64.lld has ported the option. >>   The feature is like ld.lld --section-ordering-file='s superset with >>   filename support. The syntax also supports "x86_64:" prefix, but this >>   design seems quite unusual in linker features. >> >>   This option is used by iOS mobile applications. >> >>   example: >>   https://github.com/llvm/llvm-project/blob/main/lld/test/MachO/order-file.s > >Hmm, the order files in that example appear to be specifying the order of symbols >relative to each other, rather than sections. Presumably the code locates the >input section containing the symbol and places it before/after the input section >containing the other symbol. Assuming that both sections are going to be mapped >onto the same output section. > >I am not sure about usefulness of the architecture specifiers. I would have >thought that if necessary the build system could have per-architecture ordering >files. > > >>* gold --section-ordering-file=: which might be most similar to this patch. >>   I believe this option is effectively unused in the wild. > >I have had reports from customers saying that one of the reasons they do not >want to switch from gold to lld or ld.bfd is that they use gold's section >ordering file option. Interesting. I wonder whether they are fine with changing .text.a .text.b .text.c .data.x .data.y to a b c x y >>   People find the section-based naming approach too inconvenient. >>   This is incompatible with sections that are not suffixed and clang >>   -fno-unique-section-names. > >I did not know about that option. Thanks for pointing it out. > >Maybe an approach based upon symbol names would be better. Harder >to implement, but better from a user's point of view... Hmm. > Yes... The symbol order approach avoids the issue raised in the discussion on ".t/.text" at https://sourceware.org/pipermail/binutils/2024-April/133879.html . There is a potentially more efficient implementation. See below. >>* ld.lld --symbol-ordering-file=: >> >>   This option is used by Android and regular Linux folks focusing on server performance. >> >>   example: >>   https://github.com/llvm/llvm-project/blob/main/lld/test/ELF/symbol-ordering-file.s >> >>   I have some notes at >>   https://maskray.me/blog/2020-11-15-explain-gnu-linker-options#symbol-ordering-filefile > >Very hepful. I wish that I had read this before starting to adapt H.J.'s code... > Thanks! >>> To my mind if the section ordering file contains the following: >>> >>>    # A comment >>>   .text.hot .text.cold,.text.warm >>>   .data.big >>>   .data.small >>>   .text.foo* >> >>> Then this should be roughly equivalent to: >>> >>> SECTIONS >>> { >>>   .text : { >>>     *(.text.hot) >>>     *(.text.cold) >>>     *(.text.warm) >>>     *(.text.foo*) >>>     *(.text) >>>     } >>>   .data : { >>>     *(.data.big) >>>     *(.data.small) >>>     *(.data) >>>     } >>> } >>> >>> So all of the .text. entries in the section ordering >>> file are placed at the start of the output .text section (even >>> if some of them occur after entries for other output sections) >>> and all of the .data. entries are placed at the start >>> of the .data section. >>> >>> This will require co-operation from the linker script to have >>> the "INCLUDE config.section-ordering-file" statements at the >>> correct places, but I think that it could work. >> >>Hmm.  I am curious why the first INCLUDE (in .text) does not append >>.data.big/.data.small (as requested). > >Because the entries in the ordering file are matched to the output >section name. So an entry that starts with .text will be matched >to the .text output section and an entry that starts with .data >will be matched to the .data output section. > >In the updated patch now posted to the binutils list, I have also >implemented an explicit section name matching feature. So if the >entry in the ordering file looks like this: > > .text(.data) > >then it will be matched to the .text output section and will place >all input sections called .data at that point in the output. > >Cheers > Nick > It seems that section selection is followed by sorting (--sort-section/SORT* keywords). In essence, the section order implementation combines the linker script and the section order to create the final section selection. However, this approach relies on heuristics (which can be somewhat fragile) to correctly associate sections like .data.x and .data.y with the output section .data instead of something like .text. (There will be more ambiguity whether .text.a should be placed into .t) A symbol order implementation iterates over the symbol list and assigning a priority to the associated section for each defined symbol. Unmatched sections receive a priority of 0. Here's an example: a.o:.text.a -5 (highest priority) b.o:.text.b -4 a.o:.text.c -3 b.o:.data.x -2 b.o:.data.y -1 (lowest priority) ... other sections 0 (no priority) After the --sort-section/SORT* command sorts the input section description, it's further sorted (stable sort) based on the assigned priorities. For example, with an input description of *(.text .text.*), the priorities will guide the sorting of the matched sections. In his presentation "Speeding up the BFD linker", Michael optimized section selection. He might have insights into where symbol ordering could be implemented effectively.