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 2040B3858D39 for ; Wed, 2 Mar 2022 16:57:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2040B3858D39 Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-664-UGmU2TxvPb64CZcv6FOtZA-1; Wed, 02 Mar 2022 11:57:42 -0500 X-MC-Unique: UGmU2TxvPb64CZcv6FOtZA-1 Received: by mail-wm1-f69.google.com with SMTP id p35-20020a05600c1da300b0038151176781so1034726wms.7 for ; Wed, 02 Mar 2022 08:57:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=hCjo4YG6zjH/sUxlwKEtyKjRJWDNfnoZQ/FMcfqLkmQ=; b=cWs4/4XreeFqinp8uiBYyQ6npRNOkf40PV+EIdgcBcftNv8qZAPcDh6EWzmhCBjXAF zlj12Kq/xQtw5uC6384ZuOL9mFktxe/Imm4ZqycUphS3hVJ+nPhvaQuYbI3i60O1l9sr Ryr6YNrrfyUvkLlxLkZ6pRTBwQ/LD/mcz7exOS1FGmjc+WJw18gtQu20LnsY9IMMemH7 8oE6ZhZ4JEGiQ0MfOadZiNQileVrxkPP01X6h59/+oUsGNJVnH1eCjf/dITEr4rcwx0B MPfbD7U9oV+tHwoU4VnTveqhQ3SQDfJ6wWR1eLLJEXsPtxEBsZxhqrUWPMGCL/wyuiab A8dA== X-Gm-Message-State: AOAM533GZRulqJvy1rcIuWqG9IiGCZyYwNGKiF8msie95YDWCdGVyGQ2 YVBVVesCcMR2tfThJM2y7gu8w5R+dslAALxrCCgivKFsye9k6rhHfthQ0jSqOh7KwfB7hE9yyDN Mp5f0HOvXWTu5trCKZw== X-Received: by 2002:a05:6000:1e0c:b0:1f0:95f:42e7 with SMTP id bj12-20020a0560001e0c00b001f0095f42e7mr6851850wrb.239.1646240261215; Wed, 02 Mar 2022 08:57:41 -0800 (PST) X-Google-Smtp-Source: ABdhPJxf01Zw+qong3DSQrtix8LkBe7FJrIdvf70PWxLYlU9ZJNh2vUsItrHRPfyOGPeVNB3hmKmwA== X-Received: by 2002:a05:6000:1e0c:b0:1f0:95f:42e7 with SMTP id bj12-20020a0560001e0c00b001f0095f42e7mr6851842wrb.239.1646240260956; Wed, 02 Mar 2022 08:57:40 -0800 (PST) Received: from localhost (host86-169-131-29.range86-169.btcentralplus.com. [86.169.131.29]) by smtp.gmail.com with ESMTPSA id z16-20020a7bc7d0000000b00381004c643asm6001695wmk.30.2022.03.02.08.57.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Mar 2022 08:57:40 -0800 (PST) From: Andrew Burgess To: Jan Beulich , Binutils Subject: Re: ld's --orphan-handling vs empty linker-generated sections In-Reply-To: References: Date: Wed, 02 Mar 2022 16:57:39 +0000 Message-ID: <87v8wwxpfg.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2022 16:57:49 -0000 Jan Beulich via Binutils writes: > Hello, > > we've been considering to make use of this command line option to > trigger warnings during the building of Xen. I'm puzzled though by > the warning being issued for certain linker generated (as per the > sections' flags) sections. > > For one there's .got, .plt, and alike. When building OS-kernel-like > binaries, these are often expected (or even required) to be empty. > Hence I would have thought there shouldn't be a need to name these > in the linker scripts, but I don't see how else I could silence the > resulting warnings. > > The other yet more puzzling set are various .rela.* sections. I > can't even derive on what basis these are made. For example I see > one for .text and .data.rel.local, but none for .data. No > relocations are to remain anyway (we're not asking for them to be > retained), so their origin is quite unclear to me. I do note though > that the various scripts under ld/scripttempl/ indeed mention them. > I have to admit that I wasn't aware these need mentioning; I was > rather expecting they would be like e.g. .symtab and .strtab, which > also aren't explicitly named. > > My first thought was to simply suppress the warning for empty linker > generated sections in ldlang_place_orphan(). But it looks like final > section sizes aren't known yet at that point, so "emptiness" cannot > be determined at this point. Most sections are still empty at that > time (but may not be in the end), while at least for x86-64 .got.plt > isn't empty at this point, yet doesn't appear in the final binary. > > I would appreciate any insight here as well as hints towards the > "canonical" silencing of this diagnostic. Having to enumerate all > sections the linker might instantiate (and then drop again from the > output for being empty) doesn't really work well, after all. As soon > as new ones appear, one would need to fiddle with linker scripts > again. Just for context, when I originally proposed this flag, I was working on smaller embedded targets for which .plt, .got, etc were not an issue. As a result, I never really considered how these might be handled. It's possible something has been added between then and now, but, it might also be the case that there is no "canonical" solution for what you want, you may have to invent one! Good luck, Andrew