From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) by mx.groups.io with SMTP id smtpd.web10.83979.1680555529276660622 for ; Mon, 03 Apr 2023 13:58:49 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@posteo.de header.s=2017 header.b=K6laICrh; spf=pass (domain: posteo.de, ip: 185.67.36.65, mailfrom: mhaeuser@posteo.de) Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 5B7C62403B8 for ; Mon, 3 Apr 2023 22:58:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1680555527; bh=Pthm/ripCjVtAaswynH+gUp80Sk6QiXG85lfzeoMpEw=; h=From:Subject:Date:Cc:To:From; b=K6laICrhvKjPNpCRnN+Mf97eOhYfmtyAzhFYbKuSiD8LZStLWV4IbbaqBFyzaT+JK POlzBRijybeNVX8y49JvUZPDCaiy0EX1wtRiqnkjGKUc4PoxRmj2x86hOOgebamzQo Nj5PSWKjbPDwy4CmDsyxv2sONdhBJAu8yR/WKz4P4YpfetUREEOLfd+uhbvwV7gaM5 GYAurktaledejCf6AihVdWO5HKxId0FHx7DW9oafGtIXlvqTnnuxEBIqtLZD3Sw2uz 7bcKe/15ZnbtgXJtIvWQwV+9Pnu1d51CiebzFSQyLjcnPVIceUZq+8MJuakHkXsQh+ 9+cII/4XzYsOg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Pr3CS6PRgz9rxB; Mon, 3 Apr 2023 22:58:44 +0200 (CEST) From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= Mime-Version: 1.0 (1.0) Subject: Re: Linker scripts use of "-z common-page-size=0x20" etc. Date: Mon, 3 Apr 2023 20:58:44 +0000 Message-Id: <668CD723-746F-4A04-B5E8-7DD55AECD55F@posteo.de> References: <9befc3e1-02b6-c0c4-7eba-cccd84dedd3d@bsdio.com> Cc: Pedro Falcato , Liming Gao , Ard Biesheuvel , devel@edk2.groups.io In-Reply-To: <9befc3e1-02b6-c0c4-7eba-cccd84dedd3d@bsdio.com> To: Rebecca Cran Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 3. Apr 2023, at 22:33, Rebecca Cran wrote: >=20 > =EF=BB=BFAs 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 "Se= ction address not aligned to its own alignment.". >=20 > The following messages are printed: >=20 >=20 > 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 o= f alignment (16) >=20 > I tracked the problem down to GccBase.lds and ClangBase.lds, which have: >=20 > /* * The alignment of the .data section should be less than or equal to th= e * alignment of the .text section. This ensures that the relative offset * b= etween these sections is the same in the ELF and the PE/COFF versions of * t= his binary. */ .data ALIGN(ALIGNOF(.text)) : ALIGN(CONSTANT(COMMONPAGESIZE))= { *(.data .data.* .gnu.linkonce.d.*) *(.bss .bss.*) } >=20 > I can work around the problem by removing "ALIGN(ALIGNOF(.text)", but I'm w= ondering if our use of COMMONPAGESIZE/MAXPAGESIZE is correct. >=20 >=20 > We pass in a value of 0x20, 0x40 or 0x1000 to "-z common-page-size" with 0= x20 being the most common value. >=20 > Given the page size of the target will never be 32 bytes, the following co= mment on https://reviews.llvm.org/D61688 makes sense: >=20 >=20 > "There is at least one linkerscript in Tianocore edk2 that (ab)uses -n -z c= ommon-page-size=3D0x20 to use CONSTANT(COMMONPAGESIZE) as if it were a prepr= ocessor macro set with -D in the compiler. The usual approach to this is to p= re-process the linkerscript." >=20 >=20 > I'm wondering what the correct approach is here: should we do something si= milar 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 i= gnore how it's normally used to specify the maximum allowable page size for a= n executable? That last part is actually not ignoring the use-case, that *is* our use-case= . The terminology again is very OS-oriented, it=E2=80=99s important to know t= hat generally OSes will fail to load binaries that are aligned less than the= platform page size, as they cannot apply permissions (and probably also som= e implementation details of mmap / VM / whatever). That=E2=80=99s why the ma= ximum page size you=E2=80=99re realistic to encounter is exactly the image s= egment alignment (by hardware convention, this is a power of two, thus a str= ict alignment satisfies all less strict alignment constraints). The common page size on the other hand appears to be an optimization, for wh= ich you specify the most common page size (e.g., you may target AARCH64 whic= h may require 16 KB alignment, but most of your targets will have only 4 KB p= ages), which the compiler will use to optimize the binary for the common tar= gets. I have no idea why this is even used. There also were discussions on L= LVM platforms that it should be avoided. The naive approach would be to just use max-page-size, drop all references t= o common-page-size, and align all ELF sections that will be converted to PE s= ections by max-page-size. But I=E2=80=99m sure there=E2=80=99s some ancient w= orkaround / compiler bug / edge use case / portability or whatever reason wh= y common-page-size was used. :) (CC Leif for related experience.) edk2 generally sets this to a low value to save SPI (and possibly RAM) space= , as nothing in the stack enforces memory protection ( :( ). I=E2=80=99m not= sure why there=E2=80=99s both 32 and 64 Bytes, but I could imagine it=E2=80= =99s some GNU ABI thing where some type of some arch actually requires this a= lignment, or maybe there=E2=80=99s different rules for global variables. A t= ext segment must at least satisfy the maximum instruction alignment constrai= nt (this may be a thing with, e.g., normalised instruction lengths), while d= ata segments must satisfy at least the maximum data alignment constraint (wh= ich might usually be some large float? Not sure). 4 KB is used when memory p= rotection is needed (usually RT drivers, as they=E2=80=99re mapped into the O= S environment), but AARCH64 may actually require 16 KB (e.g. Apple A chips d= idn=E2=80=99t even support less for a while). Best regards, Marvin >=20 >=20 > --=20 > Rebecca Cran >=20