Date: Mon, 16 Feb 2026 12:30:47 -0800 From: Ahmad Khalifa <ahmadkhalifa570@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Jessica Clarke <jrtc27@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "dev-commits-src-all@freebsd.org" <dev-commits-src-all@freebsd.org>, "dev-commits-src-main@freebsd.org" <dev-commits-src-main@freebsd.org> Subject: Re: git: a60e7e6ff0ec - main - stand: compile ia32 EFI loader with -malign-double Message-ID: <CAMLT6uCDfZ8_3-oVNA7bEA3icrJw7cirAFvyBQ3S1LbKVsG4CA@mail.gmail.com> In-Reply-To: <CANCZdfoHQxt-s377Q0isdZab%2BAd76ncU9hPt9Ee_YYYSm52aSg@mail.gmail.com> References: <6991d07b.43f21.696cde4f@gitrepo.freebsd.org> <0B6A645E-D9E4-4337-B280-7E3CBA1FDC1B@freebsd.org> <CAMLT6uBpSKUH9Q6RRg65-jtW%2BoO3-TK0TeejqbVXxnrND2EQPQ@mail.gmail.com> <CAMLT6uDpnYb%2B1DFCwYizOku%2Bpa4%2BAxGMa%2BFhJGztTjVpdyx9sw@mail.gmail.com> <CANCZdfoHQxt-s377Q0isdZab%2BAd76ncU9hPt9Ee_YYYSm52aSg@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
On Mon Feb 16, 2026 at 3:29 AM +0200, Warner Losh wrote: > On Sun, Feb 15, 2026 at 8:56 AM Ahmad Khalifa <ahmadkhalifa570@gmail.com> > wrote: > >> On Sun Feb 15, 2026 at 4:27 PM +0200, Ahmad Khalifa wrote: >> > On Sun Feb 15, 2026 at 4:02 PM +0200, Jessica Clarke wrote: >> >> On 15 Feb 2026, at 13:56, Ahmad Khalifa <vexeduxr@FreeBSD.org> wrote: >> >>> >> >>> The branch main has been updated by vexeduxr: >> >>> >> >>> URL: >> https://cgit.FreeBSD.org/src/commit/?id=a60e7e6ff0ec1fdd66c2568ac6c03b843dbb3c9d >> >>> >> >>> commit a60e7e6ff0ec1fdd66c2568ac6c03b843dbb3c9d >> >>> Author: Ahmad Khalifa <vexeduxr@FreeBSD.org> >> >>> AuthorDate: 2026-02-15 12:23:26 +0000 >> >>> Commit: Ahmad Khalifa <vexeduxr@FreeBSD.org> >> >>> CommitDate: 2026-02-15 13:30:06 +0000 >> >>> >> >>> stand: compile ia32 EFI loader with -malign-double >> >>> >> >>> The UEFI spec says: >> >>>> Structures are aligned on boundaries equal to the largest internal >> >>>> datum of the structure and internal data are implicitly padded to >> >>>> achieve natural alignment. >> >>> >> >>> By default, structs containing members of type "long long" have 4 >> byte >> >>> alignment on i386. This caused some EFI structures to be subtly >> wrong. >> >>> >> >>> Fix this by compiling the ia32 EFI loader with -malign-double, which >> >>> bumps the alignment up to 8 if such members are present. >> >> >> >> This seems like a dangerously big hammer. Are there any types shared >> >> with libsa or the kernel itself that would change layout? (I suppose >> >> for the latter they already need to be aligned as the kernel is 64-bit?) >> > >> > For the kernel, any shared types would have already needed to be >> > aligned, yes. I didn't consider shared types with either libsa or libefi >> > though, I'll look into it now. Nice catch. >> > >> >> Okay, so libsa, libefi, liblua and ficl all share types with the loader. >> Quite obvious in hindsight... I'll back this out until I come up with >> something better. >> > > Yea, EFI lives in two worlds: The world of having to make UEFI calls, > which has one calling convention and ABI (including structures), and then > it also lives in the world of creating some binary structs for the kernel. > These > have to agree somehow. > > It's even worse, since the 32-bit loader code is also shared with the BIOS > loader, which has some different layout conventions... > > If we have to do this, we'd likely need another libsa32 etc for the new > conventions. Yep, that's the problem I ran into. I'd rather we have a more elegant solution, but this is the only one that comes to mind. > > I'm curious, which structures does this affect. UEFI / EDK2 tries hard to > make details > like this not matter. I ran into it with EFI_MEMORY_DESCRIPTOR. It wasn't immediately noticable since the kernel parsed the memory map with the correct layout. However, something as simple as this causes problems: struct { UINT32 a; UINT64 b; }; I looked into what EDK2 does, and it seems like they just pass -malign-double to their IA32 builds. > > >> >> >> >> Annotating just the EFI types would seem more appropriate, like how we >> >> annotate function pointers to use the Microsoft calling convention. >> > >> > They're all under contrib unfortunately. Not sure if we want to >> > introduce that big of a diff with upstream. >> > >> >> >> >> Jessica >> >>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMLT6uCDfZ8_3-oVNA7bEA3icrJw7cirAFvyBQ3S1LbKVsG4CA>