Re: git: a60e7e6ff0ec - main - stand: compile ia32 EFI loader with -malign-double

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
>>
>>