From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mx.groups.io with SMTP id smtpd.web10.98421.1680606626318615701 for ; Tue, 04 Apr 2023 04:10:26 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="signature has expired" header.i=@bsdio.com header.s=fm3 header.b=ehEpGntE; spf=pass (domain: bsdio.com, ip: 66.111.4.27, mailfrom: rebecca@bsdio.com) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D39D05C0192; Tue, 4 Apr 2023 07:10:23 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 04 Apr 2023 07:10:23 -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:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1680606623; x=1680693023; bh=BoNtbPbojL1jYgipNuj6Jy3SFj7wcS3lLJU QL9bQmus=; b=ehEpGntE8zNSrv1yXxOsEljovHzGF8n6pChUIcjPtmrBqv6plWH YuGY6K4wuqyaZ5oL+5j3b2LyEVtVIpPLt810fxO1eOEUO0S7Kd880CRgSih0IEjI nyOVnuQzsI/IH2R29B7yL49pGLBolkef+JJPc3CugEMBzusX+a3D2W37RYePVlPn xLY+Zd0Z5P/yGg3MqZvsbUh7RAcYbYJEXmrZXV/tkrkmr9FZHdDf3ZY79dad8Xcp EFlymwOWz8CjgRxYeSHAlNE3b7ktxg76KDQLp6bERtUQCY0swVkaC/LOu1bueZT5 vyThuKfDwaoPA9kUObBTKX3s1crvwPeXhtQ== 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:in-reply-to:message-id:mime-version :references: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= 1680606623; x=1680693023; bh=BoNtbPbojL1jYgipNuj6Jy3SFj7wcS3lLJU QL9bQmus=; b=d3hCuhMFzDN4YDJzSfsRzkm+q+RP4Rb7XE4ksx+CUICcv5LPgAu ouUht8kNqZmMkWG5joMlVuwd9LXXbchimYvq3/t1mjIQclwiO4Z6fF4zMPluomRf vF0dqkOLHzSvQAcK1JtPHpOKznw0dcLoGOtp/EgkmrtI6oWKC5/jjNKjkYsJ8Fxj D7GkJ62QS0d348QLljjyH658R3tBEPHVFZQ+mgE1II7VVgbKDzm+Y50nCE1r0U34 dInMiLO5pBoM+Ve4Y/emMHcwItt+GY8D96V4YyYfg2ByVNYP26EDYuxoRBn7em6A jIcHpOv84LRRJ2ou7hz/5hlWcE4x63g2exQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdeiledgfeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeftvggs vggttggrucevrhgrnhcuoehrvggsvggttggrsegsshguihhordgtohhmqeenucggtffrrg htthgvrhhnpefgvdefgedvveeiffeuudeukeejgfelueeifeelfeekgfeufeefieetjedt geeiieenucffohhmrghinheplhhlvhhmrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomheprhgvsggvtggtrgessghsughiohdrtghomh X-ME-Proxy: Feedback-ID: i5b994698:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 4 Apr 2023 07:10:22 -0400 (EDT) Message-ID: <5c7df62e-2802-6a70-49a4-3af5c1625a16@bsdio.com> Date: Tue, 4 Apr 2023 05:10:21 -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 Subject: Re: Linker scripts use of "-z common-page-size=0x20" etc. To: Ard Biesheuvel Cc: Pedro Falcato , =?UTF-8?Q?Marvin_H=c3=a4user?= , Liming Gao , Ard Biesheuvel , "devel@edk2.groups.io" References: <9befc3e1-02b6-c0c4-7eba-cccd84dedd3d@bsdio.com> From: "Rebecca Cran" In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/4/23 1:22 AM, Ard Biesheuvel wrote: > On Mon, 3 Apr 2023 at 22:33, Rebecca Cran wrote: >> 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.". >> > Stupid question: if it breaks stuff, why do you use -n ? As far as I can see, clang adds it automatically when it invokes ld.lld. >> 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. >> > What do you mean by 'correct'? The intent is clearly to declare the > mapping granule size, and for SEC/PEI binaries that execute in place > from flash, the MMU page size is not the most useful quantum here. On Discord, I think Marvin was saying that we shouldn't be using COMMONPAGESIZE, but MAXPAGESIZE. Since .text is aligned to COMMONPAGESIZE, I think I can remove the ALIGN(ALIGNOF(.text)) and keep the ALIGN(CONSTANT(COMMONPAGESIZE))? > 'Page size' is highly context specific, and toolchain people are > (imho) usually quite quick to call something abuse if it does not > match their narrow definition of how a compiler or linker should be > used. For the same reason, it has been so difficult to get a compiler > to understand that the desire for position independent code does not > imply that we want GOTs, or care about ELF symbol preemption or > copy-on-write footprint of relocatable segments. In general, the bare > metal use case (which includes EFI) is quite poorly understood by many > people working on toolchains. > >> 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? > We cannot, that is the reason for using the page size switches here: > using a symbol to set the location pointer is fine, but using a symbol > to set the alignment of a section is not. > >> 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? >> > Note that (when I last checked), the only effect of setting -z > xxx-page-size is that those macros assume the associated value in the > linker script. Nothing else in the linker changes behavior (with the > exception of the warning you are seeing) > > So claiming abuse because the provided value does not match the page > size of an OS that might also run on the same system is strenuous, and > I think our use of it is fine. AIUI, the reason for having > ClangBase.lds in addition to GccBase.lds is the fact that LLD does not > support common but only max page size, so I think it should be fine to > merge the two, and use max-page-size everywhere. Thanks for the explanation. This is probably an error on my part, but when I tried to use max-page-size everywhere, the AARCH64 build of ArmVirtQemu failed, with GenFw saying "AARCH64 small code model requires identical ELF and PE/COFF section offsets modulo 4 KB." LLD added support for common-page-size in 2019 (https://reviews.llvm.org/D56205), so I think we can keep the current usage of common and max page size and just combine GccBase.lds and ClangBase.lds. -- Rebecca Cran