From nobody Fri Apr 26 16:40:40 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=quarantine dis=none) header.from=suse.com ARC-Seal: i=1; a=rsa-sha256; t=1619175839; cv=none; d=zohomail.com; s=zohoarc; b=Ni+KT1aFPQI441ECDEhxiqQRGr1ag+ONPo0BusDk6HsunqpYZJlRjinQzFoy0zzn8+symLyausQIamGsIFXMa44cFtSPyP5T0o2adZKzC/9NVQiVGIMlvKS+JnuoW0HSm6RjysjS8G5iPDSEAmlhVDCQdz4I7yKLLdm5iGlOaOA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1619175839; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=gtsBQVM6fXHKsNwZadOnV9fPekSRbF3U9lRQ6dy2Lxs=; b=Du067z26roZIl7QBRa36R21eVnJ/cI3mpwcmOtqUq8PpXWPSAPx9sENRGjr0jXf+CwlbMRft8RLnM44SL2qmTTjXwURtRFP4WDr/gYpoz5bpt2mH1TaEicbuM/9TFLT4uOWgbx2iSGxXaU2uY1ICwCgbxavXMeB2RgYDwN5rqjI= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=quarantine dis=none) header.from= Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1619175839780601.4819477475073; Fri, 23 Apr 2021 04:03:59 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.116193.221823 (Exim 4.92) (envelope-from ) id 1lZtaz-0005oo-6X; Fri, 23 Apr 2021 11:03:37 +0000 Received: by outflank-mailman (output) from mailman id 116193.221823; Fri, 23 Apr 2021 11:03:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lZtaz-0005oh-3P; Fri, 23 Apr 2021 11:03:37 +0000 Received: by outflank-mailman (input) for mailman id 116193; Fri, 23 Apr 2021 11:03:36 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lZtay-0005oa-BQ for xen-devel@lists.xenproject.org; Fri, 23 Apr 2021 11:03:36 +0000 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b60d196c-89dd-4628-bd93-a871f5e31660; Fri, 23 Apr 2021 11:03:35 +0000 (UTC) Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id B019FB10B; Fri, 23 Apr 2021 11:03:34 +0000 (UTC) X-Outflank-Mailman: Message body and most headers restored to incoming version 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: b60d196c-89dd-4628-bd93-a871f5e31660 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=1619175814; 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=gtsBQVM6fXHKsNwZadOnV9fPekSRbF3U9lRQ6dy2Lxs=; b=X83AGop41/LmzdecgL+3Urc1U4teWi+xBRqV307GrvJTMvUn+Jxz7YTADg3d4Y2Q0e4Esh r+JwJgBVUwp+4X/RwJHBjxeSVBEhsu3U98dE5R2cUtAuK7K46kGD3b6uCIhrJbh3IWqdV+ +ieldNxlQBO+zCA7/SeJ1YdhAGwlee0= Subject: [PATCH v2 1/3] x86/EFI: sections may not live at VA 0 in PE binaries From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <89e97459-28fd-704f-d424-88afa3a2a4a5@suse.com> Message-ID: <748d35dc-5a2f-302f-d789-9797c6726810@suse.com> Date: Fri, 23 Apr 2021 13:03:34 +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: <89e97459-28fd-704f-d424-88afa3a2a4a5@suse.com> Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @suse.com) Content-Type: text/plain; charset="utf-8" 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. Signed-off-by: Jan Beulich Acked-by: Roger Pau Monn=C3=A9 --- It's certainly odd that we have stabs section entries in the script, but no Dwarf ones. --- a/xen/arch/x86/xen.lds.S +++ b/xen/arch/x86/xen.lds.S @@ -350,6 +350,7 @@ SECTIONS #endif } =20 +#ifndef EFI /* Stabs debugging sections. */ .stab 0 : { *(.stab) } .stabstr 0 : { *(.stabstr) } @@ -358,6 +359,7 @@ SECTIONS .stab.index 0 : { *(.stab.index) } .stab.indexstr 0 : { *(.stab.indexstr) } .comment 0 : { *(.comment) } +#endif } =20 ASSERT(__2M_rwdata_end <=3D XEN_VIRT_END - XEN_VIRT_START + __XEN_VIRT_STA= RT - From nobody Fri Apr 26 16:40:40 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=quarantine dis=none) header.from=suse.com ARC-Seal: i=1; a=rsa-sha256; t=1619175869; cv=none; d=zohomail.com; s=zohoarc; b=UtOCTNGOs+J9Qd+0or3Wi+t5QKiAaDv3Q+Eppj5f1zxZRlseNejGkb4nd/W/rEaJyiZMxqzgWsq7Nexz/rXkp9/aG8haAwISyUndIvsrEZzHd5XSDtWStXPj/yA/6C0Io8DjHiCz8PS1Gt/TN2M3CClxaECBqnAxDkW7hEnJBfY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1619175869; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=3E4zY1ba3W2J+Wx0AnoEmzDCGCNqdtMSeVue/LO/Frk=; b=ZtWnuwzcHzaV7Fl/sfFy4L1JDjmBaHcS+5ZL12Np/wgqfxA7y8A2Jkgx+5Hgt2+ejKS0e1gMMcyjTxdyyhnk2s244eV74XThuz75ai8nDeMC6B/QzWAs2SFQYzg7LLyvdiAa0cMKavkl7o55CzL5YEpsPwps7T6Drhq2T8M6RsI= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=quarantine dis=none) header.from= Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1619175869628495.49590586920453; Fri, 23 Apr 2021 04:04:29 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.116196.221834 (Exim 4.92) (envelope-from ) id 1lZtbZ-0005v3-FI; Fri, 23 Apr 2021 11:04:13 +0000 Received: by outflank-mailman (output) from mailman id 116196.221834; Fri, 23 Apr 2021 11:04:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lZtbZ-0005uw-CC; Fri, 23 Apr 2021 11:04:13 +0000 Received: by outflank-mailman (input) for mailman id 116196; Fri, 23 Apr 2021 11:04:12 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lZtbY-0005uo-9E for xen-devel@lists.xenproject.org; Fri, 23 Apr 2021 11:04:12 +0000 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 60db8bb4-ba7b-4966-9e62-05e671b44324; Fri, 23 Apr 2021 11:04:11 +0000 (UTC) Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 7B153B0D0; Fri, 23 Apr 2021 11:04:10 +0000 (UTC) X-Outflank-Mailman: Message body and most headers restored to incoming version 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: 60db8bb4-ba7b-4966-9e62-05e671b44324 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=1619175850; 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=3E4zY1ba3W2J+Wx0AnoEmzDCGCNqdtMSeVue/LO/Frk=; b=UXHKBV5YlqGmVQOdZENFX6MBQ856rFAbZRnaQUbP/FNzR8iDTyoqoTNWGPM9Htwx/RSp/d SrTV8qP2xIp8rk7koz0dD+aqRMRIt6nJ9WcD+w3b8XchenYvTCCzrt+KgaWgFbz1z4IwOi McaKmNytJ+3OREHdB2/pd4EeP27n9S0= Subject: [PATCH v2 2/3] x86/EFI: keep debug info in xen.efi From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <89e97459-28fd-704f-d424-88afa3a2a4a5@suse.com> Message-ID: <084ef874-3ef2-cb52-bc4b-3b9d78c826ae@suse.com> Date: Fri, 23 Apr 2021 13:04:10 +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: <89e97459-28fd-704f-d424-88afa3a2a4a5@suse.com> Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @suse.com) Content-Type: text/plain; charset="utf-8" ... provided the linker supports it (which it does as of commit 2dfa8341e079 ["ELF DWARF in PE output"]). Without mentioning debugging sections, the linker would put them at VA 0, thus making them unreachable by 32-bit (relative or absolute) relocations. If relocations were resolvable (or absent) the resulting binary would have invalid section RVAs (0 - __image_base__, truncated to 32 bits). Mentioning debugging sections without specifying an address will result in the linker putting them all on the same RVA. A loader is, afaict, free to reject loading such an image, as sections shouldn't overlap. (The above describes GNU ld 2.36 behavior, which - if deemed buggy - could change.) Make sure our up-to-16Mb padding doesn't unnecessarily further extend the image. Take the opportunity and also switch to using $(call ld-option,...). Requested-by: Andrew Cooper Signed-off-by: Jan Beulich Acked-by: Roger Pau Monn=C3=A9 --- v2: Add comment to linker script. --- This way we could also avoid discarding .comment for xen.efi. I'd like to point out that the linking of the debug info takes far longer than the linking of the "normal" parts of the image. The change therefore has the downside of slowing down debug builds. --- a/xen/arch/x86/Makefile +++ b/xen/arch/x86/Makefile @@ -129,8 +129,14 @@ export XEN_BUILD_EFI :=3D $(shell $(CC) $( CFLAGS-$(XEN_BUILD_EFI) +=3D -DXEN_BUILD_EFI =20 # Check if the linker supports PE. -EFI_LDFLAGS =3D $(patsubst -m%,-mi386pep,$(XEN_LDFLAGS)) --subsystem=3D10 = --strip-debug -XEN_BUILD_PE :=3D $(if $(XEN_BUILD_EFI),$(shell $(LD) $(EFI_LDFLAGS) -o ef= i/check.efi efi/check.o 2>/dev/null && echo y)) +EFI_LDFLAGS =3D $(patsubst -m%,-mi386pep,$(XEN_LDFLAGS)) --subsystem=3D10 +XEN_BUILD_PE :=3D $(if $(XEN_BUILD_EFI),$(call ld-option,$(EFI_LDFLAGS) --= image-base=3D0x100000000 -o efi/check.efi efi/check.o)) +# If the above failed, it may be merely because of the linker not dealing = well +# with debug info. Try again with stripping it. +ifeq ($(CONFIG_DEBUG_INFO)-$(XEN_BUILD_PE),y-n) +EFI_LDFLAGS +=3D --strip-debug +XEN_BUILD_PE :=3D $(call ld-option,$(EFI_LDFLAGS) --image-base=3D0x1000000= 00 -o efi/check.efi efi/check.o) +endif =20 ifeq ($(XEN_BUILD_PE),y) =20 @@ -235,6 +241,9 @@ note_file_option ?=3D $(note_file) =20 ifeq ($(XEN_BUILD_PE),y) $(TARGET).efi: prelink.o $(note_file) efi.lds efi/relocs-dummy.o efi/mkrel= oc +ifeq ($(CONFIG_DEBUG_INFO),y) + $(if $(filter --strip-debug,$(EFI_LDFLAGS)),echo,:) "Will strip debug inf= o from $(@F)" +endif $(foreach base, $(VIRT_BASE) $(ALT_BASE), \ $(LD) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $< $(relocs-dum= my) \ $(BASEDIR)/common/symbols-dummy.o $(note_file_option) -o = $(@D)/.$(@F).$(base).0 &&) : --- a/xen/arch/x86/xen.lds.S +++ b/xen/arch/x86/xen.lds.S @@ -312,10 +312,70 @@ SECTIONS *(.reloc) __base_relocs_end =3D .; } - /* Trick the linker into setting the image size to exactly 16Mb. */ - . =3D ALIGN(__section_alignment__); - DECL_SECTION(.pad) { - . =3D ALIGN(MB(16)); + /* + * Explicitly list debug section for the PE output so that they don't end + * up at VA 0 which is below image base and thus invalid. Also use the + * NOLOAD directive, despite currently ignored by ld for PE output, in + * order to record that we'd prefer these sections to not be loaded into + * memory. + * + * Note that we're past _end here, so if these sections get loaded they'= ll + * be discarded at runtime anyway. + */ + .debug_abbrev ALIGN(1) (NOLOAD) : { + *(.debug_abbrev) + } + .debug_info ALIGN(1) (NOLOAD) : { + *(.debug_info) + *(.gnu.linkonce.wi.*) + } + .debug_types ALIGN(1) (NOLOAD) : { + *(.debug_types) + } + .debug_str ALIGN(1) (NOLOAD) : { + *(.debug_str) + } + .debug_line ALIGN(1) (NOLOAD) : { + *(.debug_line) + *(.debug_line.*) + } + .debug_line_str ALIGN(1) (NOLOAD) : { + *(.debug_line_str) + } + .debug_names ALIGN(4) (NOLOAD) : { + *(.debug_names) + } + .debug_frame ALIGN(4) (NOLOAD) : { + *(.debug_frame) + } + .debug_loc ALIGN(1) (NOLOAD) : { + *(.debug_loc) + } + .debug_loclists ALIGN(4) (NOLOAD) : { + *(.debug_loclists) + } + .debug_ranges ALIGN(8) (NOLOAD) : { + *(.debug_ranges) + } + .debug_rnglists ALIGN(4) (NOLOAD) : { + *(.debug_rnglists) + } + .debug_addr ALIGN(8) (NOLOAD) : { + *(.debug_addr) + } + .debug_aranges ALIGN(1) (NOLOAD) : { + *(.debug_aranges) + } + .debug_pubnames ALIGN(1) (NOLOAD) : { + *(.debug_pubnames) + } + .debug_pubtypes ALIGN(1) (NOLOAD) : { + *(.debug_pubtypes) + } + /* Trick the linker into setting the image size to no less than 16Mb. */ + __image_end__ =3D .; + .pad ALIGN(__section_alignment__) : { + . =3D __image_end__ < __image_base__ + MB(16) ? ALIGN(MB(16)) : .; } #elif defined(XEN_BUILD_EFI) /* From nobody Fri Apr 26 16:40:40 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=quarantine dis=none) header.from=suse.com ARC-Seal: i=1; a=rsa-sha256; t=1619175889; cv=none; d=zohomail.com; s=zohoarc; b=IpIpJHaCH4sfsYgyPgrHZbhAq4YHbzWtUGgYByNnWBeCRhVxLWFs1l7oi8hQUlysXDDAfV3zZ05YsAb8n1CjJCj9lxHiWHI9soYbvqxC39qHU2aJFfhFWLvp//TWsd+GJNvFKAnad7otv+fJNTK4wPWAyFQSRY1DOjvZFmmldcw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1619175889; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=PHtI+ZWAFKtMbksWLAGrO29iTTVDU3TNyeZGMIXneH8=; b=h+pavG0nosdU/1AUOuNq/D9ZzPLCpA8TdgojsiiVDaMu2AS2EUt8DvoXAXz2l4eJlfy87pIYhU7SW7jnN4aDBvi66NCqCsc/GGJVosTV6E9/YwTRr+bG+Rn8wK7wuPUTnTc1Qcs8HFSCRKHfPpYMUYH34283bl1ocMvthU0MNDE= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=quarantine dis=none) header.from= Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1619175889084419.6326469001965; Fri, 23 Apr 2021 04:04:49 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.116199.221847 (Exim 4.92) (envelope-from ) id 1lZtbu-00060d-Nj; Fri, 23 Apr 2021 11:04:34 +0000 Received: by outflank-mailman (output) from mailman id 116199.221847; Fri, 23 Apr 2021 11:04:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lZtbu-00060W-KT; Fri, 23 Apr 2021 11:04:34 +0000 Received: by outflank-mailman (input) for mailman id 116199; Fri, 23 Apr 2021 11:04:32 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lZtbs-00060I-P6 for xen-devel@lists.xenproject.org; Fri, 23 Apr 2021 11:04:32 +0000 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0fa1e508-9a3e-4a93-a6d7-2854014ea655; Fri, 23 Apr 2021 11:04:32 +0000 (UTC) Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 50989B118; Fri, 23 Apr 2021 11:04:31 +0000 (UTC) X-Outflank-Mailman: Message body and most headers restored to incoming version 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: 0fa1e508-9a3e-4a93-a6d7-2854014ea655 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=1619175871; 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=PHtI+ZWAFKtMbksWLAGrO29iTTVDU3TNyeZGMIXneH8=; b=ZFBeNweJmgyabc5I5bXOoDJkRGRj3K4N/KPjMKnWSlXaQ5EberNE3ytXzDTetp2rb6MrDm B128mCIg7DCv8YFKiZzYVL62Ju1h3QZt84DQSpL0X3sOuQxRg1wS1Y7on2bUJJXSxnHorF PLX+EM9QCf3PgKnNiMFBthZGkCVWn0A= Subject: [PATCH v2 3/3] x86/EFI: don't have an overly large image size From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <89e97459-28fd-704f-d424-88afa3a2a4a5@suse.com> Message-ID: <0010bf45-ee8d-5518-9c17-6f8ef140185e@suse.com> Date: Fri, 23 Apr 2021 13:04:31 +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: <89e97459-28fd-704f-d424-88afa3a2a4a5@suse.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @suse.com) While without debug info the difference is benign (so far), since we pad the image to 16Mb anyway, forcing the .reloc section to a 2Mb boundary causes subsequent .debug_* sections to go farther beyond 16Mb than needed. There's no reason to advance . for establishing __2M_rwdata_end, as all data past _end is of no interest at runtime anymore anyway. Signed-off-by: Jan Beulich Reviewed-by: Roger Pau Monn=C3=A9 --- This makes more explicit a possible latent problem with the ELF image: It ends at _end, not __2M_rwdata_end (advancing . as was done here does not have the effect of increasing the image size). Interestingly the conversion xen-syms =3D> xen rounds up the program header specified size suitably, as per the comment "Do not use p_memsz: it does not include BSS alignment padding" in mkelf32.c. I do think this would instead want taking care of in the linker script. Commit 7a95e0a2c572 ("x86: properly calculate xen ELF end of image address") clearly only hacked an existing hack rather than addressing the root cause. Thoughts? --- a/xen/arch/x86/xen.lds.S +++ b/xen/arch/x86/xen.lds.S @@ -303,8 +303,7 @@ SECTIONS } PHDR(text) _end =3D . ; =20 - . =3D ALIGN(SECTION_ALIGN); - __2M_rwdata_end =3D .; + __2M_rwdata_end =3D ALIGN(SECTION_ALIGN); =20 #ifdef EFI .reloc ALIGN(4) : {