From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 2238F386F466 for ; Fri, 26 Apr 2024 10:32:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2238F386F466 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2238F386F466 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714127551; cv=none; b=JHQcNAo6ZZX60nOSlblA+oHG+op3Gtx8b6jraejN3lxXT37hUhvvgbNwpH86nxQ4SWHz/hc60gvfcmvbLzYNBW8lRPS3MEsC36OvCEfNbFnQm0n6lHpFMpHd1MDcacDyggV3QxoogMZinV7K77FYsA6dq7x2+BK10WQ566AXhVs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714127551; c=relaxed/simple; bh=qCwCyFa4HagqCNWR84j6oZQOpkRoJv9Gx+VWZmghkpc=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=A6VeZnB+y+rMzCEXwUakPJGVWAV3YjIhuFS3Thhos7JrzY1GYN00epDESkdSh4C3v1s9gGv1lc2DWSjkIEzaTiC9ifyMmqysWv1g34i6GRZx4q+39Z9WQ5UKIlAYHvt/6MZ3q3uUc+hzzlPX9MXG4KoBju+es9SrtxAt0F82OQA= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1714127540; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=wGVMq5qoP+pmOSISug65uf6nD4WAmErNwqjDCtBMY90=; b=C+pPyfCs8vV/0035NKskHgWltuWUbiJXx+ys63EdXXcg3MdLHT67GWhsnnfJImd4T4nAH2 bJVTF/kts/Hso4K1cES/RXSLL1Bow6Hfaub7H2ilHglscmx8xrhmujEEkCXOzRmTUvxGCh +kSvx7eUQYbFQhOXT3YD96Yiw4v+12U= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-206-gzSyHilTMHSBwFAihdqzxA-1; Fri, 26 Apr 2024 06:32:19 -0400 X-MC-Unique: gzSyHilTMHSBwFAihdqzxA-1 Received: by mail-qv1-f72.google.com with SMTP id 6a1803df08f44-690dd4cf6fbso21241496d6.0 for ; Fri, 26 Apr 2024 03:32:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714127538; x=1714732338; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=wGVMq5qoP+pmOSISug65uf6nD4WAmErNwqjDCtBMY90=; b=P9AQCucJecqMiKgm3zgf+n3tx5XGhGMtZoOozK0lnXlzB3wfsM2E3gx7q1cpuiOJbL qiLQEihsSjdd2lVJlbG7IAf9Pcwdv5aM9seIYJJkRk/jxAKSuTdowUlPkhjfpgjnIY04 3I4R+hF1WVzyddBEqBTml0HrCeLhIYI3Jjn9xePPpnYxA4lkmcLau8g8K/T4hgwfhd+G tcLc+4plkyiHZbg9ZtQU9Fi7JKlv53oKeA+Hhdgf4Apgu6IHDl6JRMqGdzCzqp0QQoNh jqXY+WFE3i40uS0BrLReQEo6lQVuYwJfyA8AwD9VDr82Hco7pqT4pnEHtqhcDdMCCbfE m77g== X-Forwarded-Encrypted: i=1; AJvYcCXd4EF43nykQfU4LOCCpnidljlhGl4M01WAbvgHh+J7PS5c2gziQxoz1FGm2GEGr2odE8K7vEJqba6rdUKEN/JaX3EQjGvvFA== X-Gm-Message-State: AOJu0YxPIrbSGQpFLbEuEfcMbf0Lcd9leMl3aFz/sbKdZ3ThIHsDmGI9 mf3CU1NRf1F8MNQpY9uZjwJUZuKf6uHGAn4Cpl66zT9CNHRxGxvtJhRbGE8s9Iu0UDgUfSO4Fg7 uBNoHIQJLJSWxvGtKjzOHVbteBoPvAh2G5FwEUhTObGoxqvamn51Brq+a34XDMHY= X-Received: by 2002:ad4:5ba5:0:b0:6a0:af22:e2b with SMTP id 5-20020ad45ba5000000b006a0af220e2bmr1130050qvq.24.1714127538373; Fri, 26 Apr 2024 03:32:18 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHr5ifdKBndTDpIbRNx+ek/bcapu0NGiPOb55McTdrNfB9Ghw2lHG4naaRPX1ZW4mEWySvlyA== X-Received: by 2002:ad4:5ba5:0:b0:6a0:af22:e2b with SMTP id 5-20020ad45ba5000000b006a0af220e2bmr1130033qvq.24.1714127537948; Fri, 26 Apr 2024 03:32:17 -0700 (PDT) Received: from [192.168.1.18] ([79.123.79.31]) by smtp.gmail.com with ESMTPSA id ml20-20020a056214585400b006a0b3ff2cf7sm66825qvb.39.2024.04.26.03.32.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Apr 2024 03:32:17 -0700 (PDT) Message-ID: Date: Fri, 26 Apr 2024 11:32:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: RFC: syntax for a section ordering file To: Fangrui Song Cc: "H.J. Lu" , Binutils References: <3f373229-b7cf-4229-9591-922838577652@redhat.com> <20240426030103.g62e3r7heuavejzp@google.com> From: Nick Clifton Autocrypt: addr=nickc@redhat.com; keydata= xsFNBFm/2cUBEADkvRqMWfAryJ52T4J/640Av5cam9ojdFih9MjcX7QWFxIzJfTFYq2z+nb4 omdfZosdCJL2zGcn6C0AxpHNvxR9HMDkEyFHKrjDh4xWU+pH4z9azQEqJh331X7UzbZldqQo 16VkuVavgsTJaHcXm+nGIBTcUbl2oiTtHhmuaYxx6JTMcFjC7vyO5mLBw78wt52HBYweJ0Nj HBvvH/JxbAAULSPRUC61K0exlO49VFbFETQNG1hZTKEji95fPbre7PpXQ0ewQShUgttEE/J3 UA4jYaF9lOcZgUzbA27xTV//KomP0D30yr4e4EJEJYYNKa3hofTEHDXeeNgM25tprhBUMdbV RZpf2Keuk2uDVwc+EiOVri48rb1NU+60sOXvoGO6Ks81+mhAGmrBrlgLhAp8K1HPHI4MG4gH nrMqX2rEGUGRPFjC3qqVVlPm8H05PnosNqDLQ1Pf7C0pVgsCx6hKQB7Y1qBui7aoj9zeFaQg pYef+CEERIKEcWwrjaOJwK3pi9HFdxS0NNWYZj8HPzz/AsgTTQdsbulPlVq2SsctmOnL42CZ OCTppGYwl53CG/EqVY+UQBzFzJBaY8TJRFFYVEy5/HH4H11rMoZwqIkk71EOGU3X6mWlANRi kR3M4GhVITRzuaV69Fed+OeXcCmP94ASLfuhBR2uynmcHpBKpwARAQABzTtOaWNrIENsaWZ0 b24gKENoaWVmIEJpbnV0aWxzIE1haW50YWluZXIpIDxuaWNrY0ByZWRoYXQuY29tPsLBeAQT AQIAIgUCWb/ZxQIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQE/zvid2ePE9cOxAA 3cX1bdDaTFttTqukdPXLCtD2aNwJos4vB4LYPSgugLkYaHIQH9d1NQPhS0TlUeovnFNESLaV soihv0YmBUCyL4jE52FRoTjE6fUhYkFNqIWN2HYwkVrSap2UUJFquRVoVbPkbSup8P+D8eyd BbdxsY6f+5E8Rtz5ibVnPZTib7CyqnFokJITWjzGdIP0Gn+JWVa6jtHTImWx1MtqiuVRDapU hrIoUIjf98HQn9/N5ylEFYQTw7tzaJNWeGUoGYS8+8n/0sNbuYQUU/zwMVY9wpJcrXaas6yZ XGpF/tua59t9LFCct+07YAUSWyaBXqBW3PKQz7QP+oE8yje91XrhOQam04eJhPIBLO88g6/U rdKaY7evBB8bJ76Zpn1yqsYOXwAxifD0gDcRTQcB2s5MYXYmizn2GoUm1MnCJeAfQCi/YMob R+c8xEEkRU83Tnnw3pmAbRU6OcPihEFuK/+SOMKIuV1QWmjkbAr4g9XeXvaN+TRJ9Hl/k1k/ sj+uOfyGIaFzM/fpaLmFk8vHeej4i2/C6cL4mnahwYBDHAfHO65ZUIBAssdA6AeJ+PGsYeYh qs6zkpaA2b0wT4f9s7BPSqi0Veky8bUYYY7WpjzDcHnj1gEeIU55EhOQ42dnEfv7WrIAXanO P8SjhgqAUkb3R88azZCpEMTHiCE4bFxzOmjOwU0EWb/ZxQEQALaJE/3u23rTvPLkitaTJFqK kwPVylzkwmKdvd2qeEFk1qys2J3tACTMyYVnYTSXy5EJH2zJyhUfLnhLp8jJZF4oU5QehOaJ PcMmzI/CZS1AmH+jnm6pukdZAowTzJyt4IKSapr+7mxcxX1YQ2XewMnFYpLkAA2dHaChLSU/ EHJXe3+O4DgEURTFMa3SRN/J4GNMBacKXnMSSYylI5DcIOZ/v0IGa5MAXHrP1Hwm1rBmloIc gmzexczBf+IcWgCLThyFPffv+2pfLK1XaS82OzBC7fS01pB/eDOkjQuKy16sKZX6Rt57vud4 0uE5a0lpyItC2P7u7QWL4yT5pMF+oS8bm3YWgEntV380RyZpqgJGZTZLNq2T4ZgfiaueEV4J zOnG2/QRGjOUrNQaYzKy5V127CTnRg4BYF/uLEmizLcI3O3U1+mEz6h48wkAojO1B6AZ8Lm+ JuxOW5ouGcrkTEuIG56GcDwMWS/Pw/vNsDyNmOCjy9eEKWJgmMmLaq59HpfTd8IOeaYyuAQH AsYt/zzKy0giMgjhCQtuc99E4nQE9KZ44DKsnqRabK9s3zYE3PIkCFIEZcUiJXSXWWOIdJ43 j+YyFHU5hqXfECM6rzKGBeBUGTzyWcOX6YwRM4LzQDVJwYG8cVfth+v4/ImcXR43D4WVxxBE AjKag02b+1yfABEBAAHCwV8EGAECAAkFAlm/2cUCGwwACgkQE/zvid2ePE/dqQ/6ApUwgsZz tps0MOdRddjPwz44pWXS5MG45irMQXELGQyxkrafc8lwHeABYstoK8dpopTcJGE3dZGL3JNz 1YWxQ5AV4uyqBn5N8RubcA8NzR6DQP+OGPIwzMketvVC/cbbKDZqf0uTDy3jP65OFhSkTEIy nYv1Mb4JJl3Sq+haUbfWLAV5nboSuHmiZE6Bz2+TjdoVkNwHBfpqxu6MlWka+P98SUcmY8iV hPy9QC1XFOGdFDFf1kYgHW27mFwds35NQhNARgftAVz9FZXruW6tFIIfisjr3rVjD9R8VgL7 l5vMr9ylOFpepnI6+wd2X1566HW7F1Zw1DIrY2NHL7kL5635bHrJY4n7o/n7Elk/Ca/MAqzd IZxz6orfXeImsqZ6ODn4Y47PToS3Tr3bMNN9N6tmOPQZkJGHDBExbhAi/Jp8fpWxMmpVCUl6 c85cOBCR4s8tZsvGYOjR3CvqKrX4bb8GElrhOvAJa6DdmZXc7AyoVMaTvhpq3gJYKmC64oqt 7zwIHwaCxTbP6C6oUp9ENRV7nHnXN3BlvIgCo4QEs6HkDzkmgYlCEOKBiDyVMSkPDZdsspa+ K4GlU2Swi/BDJMjtDxyo+K0M81LXXxOeRfEIfPtZ3ddxBKPva1uSsuz+pbN9d1JY8Ko5T/h1 6susi2ReUyNJEJaSnjO5z13TQ1U= In-Reply-To: <20240426030103.g62e3r7heuavejzp@google.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-GB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,BODY_8BITS,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_INFOUSMEBIZ,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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: 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. >   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. > * 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... >>  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