From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by mx.groups.io with SMTP id smtpd.web11.83410.1680554007661838545 for ; Mon, 03 Apr 2023 13:33:27 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="signature has expired" header.i=@bsdio.com header.s=fm3 header.b=dVMKmpqv; spf=pass (domain: bsdio.com, ip: 64.147.123.19, mailfrom: rebecca@bsdio.com) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id B7177320093A; Mon, 3 Apr 2023 16:33:26 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 03 Apr 2023 16:33:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdio.com; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:message-id:mime-version:reply-to :sender:subject:subject:to:to; s=fm3; t=1680554006; x= 1680640406; bh=M0GgR99oTdTm6tvQY6jNKbEHZdaWASTcFtOxcR4whEo=; b=d VMKmpqvFgulyO33NXoeQnWNIoYEEr39uOaaiPvsCHgc9VCA5g4ZO3X1wUZdd63Ur v50ii9d1Yt8MzVKzUcn3USvB1eLEOwWNGaXHFGooMnNR3yqw2V/amA7VWezGIB4J IjlDnBhsSrj0Cnsz001rPIHvgVkyjXmBz9NnZ0pwGArtvn+bADFsPGIvuY2p7Si2 4DSsk87hV0l4lxh1JKcG+5h9nvYUZMPZdIMUpX4n2CMO6x5laymu234ssy9orj7U TTDB5Tk6/AMo03+UsTdrUl8rfv1EWyrDMPAzdcTwz108dxI6Dv3m8IFu8tysmq58 f8TP0tbRRVyayuZg+bdXg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:message-id:mime-version:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1680554006; x=1680640406; bh=M 0GgR99oTdTm6tvQY6jNKbEHZdaWASTcFtOxcR4whEo=; b=eomppRFGxIsjP9o1F XuKtiHhIxf9R8a9+0fsa9R5imuUCJhJ8oAC0d2Eu3E0TS3ukIE52cjhZe+hQlEko tmCbcAQRR/OdOAK8x5O941uTdNfNbbpyCELQ2+mhPavyH3AVRkmAzWuQjlrYbrwZ ef0T+gramadPraAu+1v0wOO8Jr0C6pAeKYg8EoETtLrrYSIYAqstbE5Z9aLqiQoB q6FR4z/XDJaF+mViOIyNaRkvcF9+ECSvCtfKyQwOh6HRqWiYs7cVBLv6655xGEvQ pjJsKmtThSc2r2yXhKv5I/d0GVCACJh1q/DLVZRQmqKCML0qIyX0yE6nbr42Vwil YiFUA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdeijedgudehudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfvvefhufgtgfesthejredttdefjeenucfhrhhomheptfgvsggv tggtrgcuvehrrghnuceorhgvsggvtggtrgessghsughiohdrtghomheqnecuggftrfgrth htvghrnhepfefhgfdtueekvdegueeukedugfduheeggeehudeihefhieffgedtkeevgfff ffdvnecuffhomhgrihhnpehllhhvmhdrohhrghenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehrvggsvggttggrsegsshguihhordgtohhm X-ME-Proxy: Feedback-ID: i5b994698:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 3 Apr 2023 16:33:24 -0400 (EDT) Message-ID: <9befc3e1-02b6-c0c4-7eba-cccd84dedd3d@bsdio.com> Date: Mon, 3 Apr 2023 14:33:22 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 To: Pedro Falcato , =?UTF-8?Q?Marvin_H=c3=a4user?= , Liming Gao , Ard Biesheuvel Cc: "devel@edk2.groups.io" From: "Rebecca Cran" Subject: Linker scripts use of "-z common-page-size=0x20" etc. Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit As part of my work on the toolchain definitions, I've come across a situation where ld.lld fails to align sections correctly, due to it being invoked via clang with the '-n' option, which causes GenFw to fail with "Section address not aligned to its own alignment.". The following messages are printed: ld.lld: warning: -z common-page-size set, but paging disabled by omagic or nmagic ld.lld: warning: address (0x558) of section .data is not a multiple of alignment (16) I tracked the problem down to GccBase.lds and ClangBase.lds, which have: /* * The alignment of the .data section should be less than or equal to the * alignment of the .text section. This ensures that the relative offset * between these sections is the same in the ELF and the PE/COFF versions of * this binary. */ .data ALIGN(ALIGNOF(.text)) : ALIGN(CONSTANT(COMMONPAGESIZE)) { *(.data .data.* .gnu.linkonce.d.*) *(.bss .bss.*) } I can work around the problem by removing "ALIGN(ALIGNOF(.text)", but I'm wondering if our use of COMMONPAGESIZE/MAXPAGESIZE is correct. We pass in a value of 0x20, 0x40 or 0x1000 to "-z common-page-size" with 0x20 being the most common value. Given the page size of the target will never be 32 bytes, the following comment on https://reviews.llvm.org/D61688 makes sense: "There is at least one linkerscript in Tianocore edk2 that (ab)uses -n -z common-page-size=0x20 to use CONSTANT(COMMONPAGESIZE) as if it were a preprocessor macro set with -D in the compiler. The usual approach to this is to pre-process the linkerscript." I'm wondering what the correct approach is here: should we do something similar to how we set PECOFF_HEADER_SIZE and define a SECTION_ALIGNMENT symbol? Or, as discussed on Discord should we just use CONSTANT(MAXPAGESIZE) and ignore how it's normally used to specify the maximum allowable page size for an executable? -- Rebecca Cran