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.129.124]) by sourceware.org (Postfix) with ESMTPS id 0B420385842A for ; Mon, 4 Sep 2023 12:12:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0B420385842A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1693829542; 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; bh=rjsybzeQtLZyaKOFgUExyE/zi86VF8iqjPqUhSljwIc=; b=B3mqXDxlI7BCTtrAMXVJrI8bIEWI1B3VZdnn+O8zDxg+MmOLrdRZhhJbVb6vNSxiUkJ2Zd mMq0N1SEpdh42Bd5PgUb6KG2wQoYeek2xldNJDwgi2lxbSyL4r5Yb09H2wXehbaGVHQxpN tTYX+RNzSB23GhkH2/67WvkOki9qT+U= Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-373-MgigTYAdPqmq0w5BI6NFvA-1; Mon, 04 Sep 2023 08:12:21 -0400 X-MC-Unique: MgigTYAdPqmq0w5BI6NFvA-1 Received: by mail-qt1-f200.google.com with SMTP id d75a77b69052e-411f95b1a31so11322621cf.1 for ; Mon, 04 Sep 2023 05:12:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693829541; x=1694434341; h=content-transfer-encoding:in-reply-to:subject:from:references:cc:to :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rjsybzeQtLZyaKOFgUExyE/zi86VF8iqjPqUhSljwIc=; b=STZLlW40ltCkbQiPXcfAGxh6LzruuFWnWBNEeoCUTUrGPGt8tECODeuJRKzFFQdcJv 2W+y88JiPnJIuZX2yX9QTRJr0Yzt3T6EWvYLaV2kjQPDL1m9kEv7HRDlxGqOiColM2f0 kYFRIqrZ6VE6gPKvA+Rido52ZXqUECam2Iil+wZi3CkOe98WL2anGgXCtUNIK+fxynkG 2DeJ46PHfVgN4vzMPkpwv6TFuuCN8I1KZ6MvCOW7jyEns04OiRa22NsnOdljPJPChqtO em4WYWyVC5YM0yfyG6HvNi5PkW79Zc8Lm97KmiG4iC38T3fg6rrTLO8X4PAytRrpkHyw mYZw== X-Gm-Message-State: AOJu0Yz5P8v0JIJEUvSKLWRBI0y9WCbVqbBEmvGNSMqbwaZn2ZftDMSS tHDc4NuXYM+bWIHzElye4HG9vKtNmSUIYLyStcqzA9rVNMEY2B+dgmxE6PkyYKqeFZ647yae1OG Yd/hK6vsFes8AQhdkeg== X-Received: by 2002:ac8:5a05:0:b0:40f:f058:1478 with SMTP id n5-20020ac85a05000000b0040ff0581478mr11409927qta.30.1693829541107; Mon, 04 Sep 2023 05:12:21 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHiD22DjdlK0l8Ovj3hCG5nDeWAVPNFvxFzPNZr0w0zfIOhvKi3MzeuJYsNuDoNvczlP9acZg== X-Received: by 2002:ac8:5a05:0:b0:40f:f058:1478 with SMTP id n5-20020ac85a05000000b0040ff0581478mr11409908qta.30.1693829540806; Mon, 04 Sep 2023 05:12:20 -0700 (PDT) Received: from [192.168.1.11] ([80.168.197.243]) by smtp.gmail.com with ESMTPSA id d20-20020ac847d4000000b00403b3156f18sm3542462qtr.8.2023.09.04.05.12.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Sep 2023 05:12:20 -0700 (PDT) Message-ID: <8b17facc-30b7-ab24-efdd-6d094a57298d@redhat.com> Date: Mon, 4 Sep 2023 13:12:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 To: Kees Cook , binutils@sourceware.org Cc: maskray@google.com References: <202308291330.05609E535@keescook> From: Nick Clifton Subject: Re: ld: provide /PASSTHRU/ section rule to avoid orphan warnings? In-Reply-To: <202308291330.05609E535@keescook> 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: 7bit X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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: Hi Kees, > The Linux kernel would like to have a way for the linker to emit sections > without changing their section name, using wildcards. I take it that it is hard/impossible for the kernel build process to know beforehand what these section names will be ? If the build process did know then it could probably use a linker script fragment to ensure that they were copied through. > Normally this happens automatically if a section > doesn't match an existing rule, but then the --orphan-handling=warn > option will report it. There is currently no way to silence these > "expected sections". So one way to address this problem would be to extend the --orphan-handling option so that it does not emit messages for certain sections. This has the advantage of not needing to extend the linker script syntax. How about something like --no-warn-orphan= option which could suppress warnings for matching sections ? Or --orphan-handling=warn-except-text which would warn for any unplaced section that is not executable ? > e.g. if we had something like: > > /PASSTHRU/ : { > *(.text.*) > } > > Then stuff like ".text.func1" and ".text.func2" will pass through as-is, > but something unexpected, like ".other" would still get correctly > reported by --orphan-handling=warn. I have a feeling that this solution would be difficult to implement since the linker script processing is not really set up for generating an unknown number of output sections from a single clause in the script. I am not 100% sure of this though, since I have not actually tried to implement it. In theory the script extension seems like a good idea, although I do wonder about section ordering. For example, suppose a script had this: /PASSTHRU/ : { *(.text.*) *(.init.*) } and then you have two input files - a.o containing .text.a.foo and .init.a.foo and b.o containing .text.b.foo and .init.b.foo. In the resulting output, what order should the sections appear ? .text.a.foo .init.a.foo .text.b.foo .init.b.foo (assuming that a.o comes before b.o on the linker command line) or: .text.a.foo .text.b.foo .init.a.foo .init.b.foo (because the .text.* pattern appears before the .init.* pattern in the linker script) Or maybe no ordering should be expected and the user gets whatever the linker decides to do. Obviously it would be best if LLD and LD.BFD and LD.GOLD all supported the same solution, so lets see if we can coordinate our response. Cheers Nick