From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 103C4C433ED for ; Wed, 21 Apr 2021 10:33:01 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A202661425 for ; Wed, 21 Apr 2021 10:33:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A202661425 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.114388.217988 (Exim 4.92) (envelope-from ) id 1lZAA2-0001ng-PC; Wed, 21 Apr 2021 10:32:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 114388.217988; Wed, 21 Apr 2021 10:32:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lZAA2-0001nZ-Ln; Wed, 21 Apr 2021 10:32:46 +0000 Received: by outflank-mailman (input) for mailman id 114388; Wed, 21 Apr 2021 10:32:45 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lZAA0-0001nU-VF for xen-devel@lists.xenproject.org; Wed, 21 Apr 2021 10:32:44 +0000 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c9e5d131-4018-4409-a45e-30a201c77d5a; Wed, 21 Apr 2021 10:32:44 +0000 (UTC) Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 39A4EAEE6; Wed, 21 Apr 2021 10:32:43 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c9e5d131-4018-4409-a45e-30a201c77d5a X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1619001163; h=from:from:reply-to: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=ZSrOHyZFETTy+Q5cNQUqkrntrgvqKpTcWutAaxCAQa8=; b=kN94TTupyZaVedPxiUy2BHdG9BKXY946uj7zVOoKwDmLiVOyxpfFh+e0sjaumqg3Iv/6NA rB9IaLfyqy+z/9d07ipwBHgiE/CVSSev0WY1STJJWrX+bRMCM6OAt6UF1HIb3go4HdQCu8 UPtukIi3vBlAS7lmO0+mk3K5Xeqifz4= Subject: Re: [PATCH 2/8] x86/EFI: sections may not live at VA 0 in PE binaries To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Wei Liu References: <5d7c61b0-8441-dccc-4917-cc8a436fd96f@suse.com> From: Jan Beulich Message-ID: Date: Wed, 21 Apr 2021 12:32:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit On 21.04.2021 10:52, Roger Pau Monné wrote: > On Thu, Apr 01, 2021 at 11:44:45AM +0200, Jan Beulich wrote: >> PE binaries specify section addresses by (32-bit) RVA. GNU ld up to at >> least 2.36 would silently truncate the (negative) difference when a >> section is placed below the image base. Such sections would also be >> wrongly placed ahead of all "normal" ones. Since, for the time being, >> we build xen.efi with --strip-debug anyway, .stab* can't appear. And >> .comment has an entry in /DISCARD/ already anyway in the EFI case. >> >> Because of their unclear origin, keep the directives for the ELF case >> though. > > It's my understadng thonse sections are only there for debug purposes, > and never part of the final xen binary as they are stripped? > > Could we maybe remove the section load address of 0 and instead just > use the (NOLOAD) directive? (NOLOAD) is meaningless for PE. > Does it really matter to place them at address 0? That's the convention for ELF, and also what ld defaults to for debugging sections. > I also wonder, is this change fixing some existing bug, or it's just a > cleanup change? If there were sections at 0, the resulting PE binary would end up broken. Prior to binutils 2.37 this brokenness is silent, i.e. the linker doesn't issue any form of diagnostic. The change therefore is addressing a latent issue - if any such section started being non-empty, we'd be in trouble. > I also only see the .comment section in my binary output, so maybe > it's fine to just remove them from the script? Which binary are you referring to - ELF or PE? In the former case, yes, that's what the statement is for. In the latter case I can't see how this would be, with .comment being explicitly part of /DISCARD/ in that case. > Does the Arm linker script need a similar treatment? No idea - they don't use ld to produce a PE binary. In fact during my work on the binutils side for all of this, I was given a hint that on Arm linking ELF objects into PE output may currently not be possible at all. Jan