Date: Mon, 16 Feb 2026 14:16:30 -0700 From: Warner Losh <imp@bsdimp.com> To: Ahmad Khalifa <ahmadkhalifa570@gmail.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: <CANCZdfoJTvO2nF7%2Big5qfoznyZiU%2BUovMbJBqS3oAfvGmnRMXg@mail.gmail.com> In-Reply-To: <CAMLT6uCDfZ8_3-oVNA7bEA3icrJw7cirAFvyBQ3S1LbKVsG4CA@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> <CAMLT6uCDfZ8_3-oVNA7bEA3icrJw7cirAFvyBQ3S1LbKVsG4CA@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On Mon, Feb 16, 2026 at 1:30 PM Ahmad Khalifa <ahmadkhalifa570@gmail.com> wrote: > 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. > Hmmm, I thought they were smarter about things than that... Do you recall the details? > 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. > They do pass that, but at least once upon a time they were careful to make sure that the structures they defined didn't have 'holes' like that. They'd do an element between a and b called reserved that was UINT32. But maybe a bigger issue for the ia32 loader is: are the structures invariant between 32 and 64 bit versions? Or do we need to worry about those structures that I've passing to the kernel that we borrowed the layout and didn't change? Warner > > > > > >> >> > >> >> 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 > >> > >> > [-- Attachment #2 --] <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Feb 16, 2026 at 1:30 PM Ahmad Khalifa <<a href="mailto:ahmadkhalifa570@gmail.com">ahmadkhalifa570@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon Feb 16, 2026 at 3:29 AM +0200, Warner Losh wrote:<br> > On Sun, Feb 15, 2026 at 8:56 AM Ahmad Khalifa <<a href="mailto:ahmadkhalifa570@gmail.com" target="_blank">ahmadkhalifa570@gmail.com</a>><br> > wrote:<br> ><br> >> On Sun Feb 15, 2026 at 4:27 PM +0200, Ahmad Khalifa wrote:<br> >> > On Sun Feb 15, 2026 at 4:02 PM +0200, Jessica Clarke wrote:<br> >> >> On 15 Feb 2026, at 13:56, Ahmad Khalifa <vexeduxr@FreeBSD.org> wrote:<br> >> >>><br> >> >>> The branch main has been updated by vexeduxr:<br> >> >>><br> >> >>> URL:<br> >> <a href="https://cgit.FreeBSD.org/src/commit/?id=a60e7e6ff0ec1fdd66c2568ac6c03b843dbb3c9d" rel="noreferrer" target="_blank">https://cgit.FreeBSD.org/src/commit/?id=a60e7e6ff0ec1fdd66c2568ac6c03b843dbb3c9d</a><br>; >> >>><br> >> >>> commit a60e7e6ff0ec1fdd66c2568ac6c03b843dbb3c9d<br> >> >>> Author: Ahmad Khalifa <vexeduxr@FreeBSD.org><br> >> >>> AuthorDate: 2026-02-15 12:23:26 +0000<br> >> >>> Commit: Ahmad Khalifa <vexeduxr@FreeBSD.org><br> >> >>> CommitDate: 2026-02-15 13:30:06 +0000<br> >> >>><br> >> >>> stand: compile ia32 EFI loader with -malign-double<br> >> >>><br> >> >>> The UEFI spec says:<br> >> >>>> Structures are aligned on boundaries equal to the largest internal<br> >> >>>> datum of the structure and internal data are implicitly padded to<br> >> >>>> achieve natural alignment.<br> >> >>><br> >> >>> By default, structs containing members of type "long long" have 4<br> >> byte<br> >> >>> alignment on i386. This caused some EFI structures to be subtly<br> >> wrong.<br> >> >>><br> >> >>> Fix this by compiling the ia32 EFI loader with -malign-double, which<br> >> >>> bumps the alignment up to 8 if such members are present.<br> >> >><br> >> >> This seems like a dangerously big hammer. Are there any types shared<br> >> >> with libsa or the kernel itself that would change layout? (I suppose<br> >> >> for the latter they already need to be aligned as the kernel is 64-bit?)<br> >> ><br> >> > For the kernel, any shared types would have already needed to be<br> >> > aligned, yes. I didn't consider shared types with either libsa or libefi<br> >> > though, I'll look into it now. Nice catch.<br> >> ><br> >><br> >> Okay, so libsa, libefi, liblua and ficl all share types with the loader.<br> >> Quite obvious in hindsight... I'll back this out until I come up with<br> >> something better.<br> >><br> ><br> > Yea, EFI lives in two worlds: The world of having to make UEFI calls,<br> > which has one calling convention and ABI (including structures), and then<br> > it also lives in the world of creating some binary structs for the kernel.<br> > These<br> > have to agree somehow.<br> ><br> > It's even worse, since the 32-bit loader code is also shared with the BIOS<br> > loader, which has some different layout conventions...<br> ><br> > If we have to do this, we'd likely need another libsa32 etc for the new<br> > conventions.<br> <br> Yep, that's the problem I ran into. I'd rather we have a more elegant<br> solution, but this is the only one that comes to mind.<br> <br> ><br> > I'm curious, which structures does this affect. UEFI / EDK2 tries hard to<br> > make details<br> > like this not matter.<br> <br> I ran into it with EFI_MEMORY_DESCRIPTOR. It wasn't immediately<br> noticable since the kernel parsed the memory map with the correct<br> layout.<br></blockquote><div><br></div><div>Hmmm, I thought they were smarter about things than that... Do you recall the details?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> However, something as simple as this causes problems:<br> struct {<br> UINT32 a;<br> UINT64 b;<br> };<br> <br> I looked into what EDK2 does, and it seems like they just pass<br> -malign-double to their IA32 builds.<br></blockquote><div><br></div><div>They do pass that, but at least once upon a time they were careful to make sure that the structures they defined didn't have 'holes' like that. They'd do an element between a and b called reserved that was UINT32.</div><div><br></div><div>But maybe a bigger issue for the ia32 loader is: are the structures invariant between 32 and 64 bit versions? Or do we need to worry about those structures that I've passing to the kernel that we borrowed the layout and didn't change?</div><div><br></div><div>Warner</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> ><br> ><br> >> >><br> >> >> Annotating just the EFI types would seem more appropriate, like how we<br> >> >> annotate function pointers to use the Microsoft calling convention.<br> >> ><br> >> > They're all under contrib unfortunately. Not sure if we want to<br> >> > introduce that big of a diff with upstream.<br> >> ><br> >> >><br> >> >> Jessica<br> >><br> >><br> </blockquote></div></div>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoJTvO2nF7%2Big5qfoznyZiU%2BUovMbJBqS3oAfvGmnRMXg>