From nobody Mon Feb 16 21:16:30 2026 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4fFFvg0dkjz6SN1Y for ; Mon, 16 Feb 2026 21:16:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4fFFvf4j3Nz47C9 for ; Mon, 16 Feb 2026 21:16:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x52c.google.com with SMTP id 41be03b00d2f7-b4755f37c3eso2492644a12.3 for ; Mon, 16 Feb 2026 13:16:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771276603; cv=none; d=google.com; s=arc-20240605; b=lcuRfQzfsZUoJb3JrkGm6bzPmdAHRmQfO8HmmdDiwlsHfqFwz8L3wt+MktflGWJ1aC cAOicbWdBTz3xt+MeRTeL4ffTjCAY8n8vL4BYqzFznSbj5pnAAu0anKp3AdLkBwG37u9 eOzdEhDyKb2Adj1Hv0ktW8Ci4yPvYwGRbkQCuiT0r/CmzKyhJyQ8OpJo6GjFhYZwsdnH ej19DU/rfU9uSQ9kCqVw8m4tciToM5bxiJlshBcard85pf5Wlc8mPaFfrjXuJHo+Ul0U hGb5zT8Fh0PgtNF/pOmvBM5RosN9h4lC9M454huPdXZJgacC8fHeTT/zm13V6vZWLldc WOWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=schAtvbneMBp6XiAV+6fB3pULomI+pBSE5fYCQHCVMQ=; fh=5n73HsInLtUXC2PdVfdYHdcJpFL81diteqIcW0uVRTo=; b=gsT5Zh6DAcuLtvNodgxElAPLpZosLDriTG8732B923s+KNfnYYBqLw9hWduaPtpI/n OZfe4Dkie2ORVaTloQohGqdaE1s86kQcHY5dVzuuVL4Lz6q/swfGvK3Qe701AXG7ZOBa jFfYIhe2SZv3J59JHsyZMq0QkTB6wgXgKvDk84ojg9PYhUfPx6DZi0/UHmtPofErOxvi qhr4wq1aCeqP6qQs8z8hgWQb1FVZtfVeXSrYy6QarQ8OJfy04sLgdRa68l9TbQ/uIS2Y dDARhS9cv7nrBq40NrTeM/EhlbrpSfFjg3/17mqjrAHRWAzn1JhzKd5qngrWYqQMC5OK 1Abw==; darn=freebsd.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1771276603; x=1771881403; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=schAtvbneMBp6XiAV+6fB3pULomI+pBSE5fYCQHCVMQ=; b=oBOOcAXfHn+mRkrtE6OR2iFVtc23kgi/FhZPvBj0TrNPvoQIoqWyE0KNFz8J9eqPLL EMCyNllcy1jGqQB9oqNkvmm4n27/yylqsjRvpeXq3pV4IQr5/Ey6tgWGJcrSWF4iHiKZ ofCv4v1Ztmn2yhtno/fvnEOPok1eiySVqvOfZO6BeNW7gsEsVoBl2Hz801BPSQuaYA2+ Kc5yQXShpUx5xK6PUdxdNEhsEI8txgq7Rmtb/mHEfr3Cl/hX6rF3JRKI/LYuW5DLYOEg e97fuKwUmIa0WYZQAHyxUksNXO7PUHwZQgPViO97EbxS7yfAz9dzU5PniIqm1sBijK09 12Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771276603; x=1771881403; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=schAtvbneMBp6XiAV+6fB3pULomI+pBSE5fYCQHCVMQ=; b=ArtNKgq7gaUcCJeLzZmyI3vBIlQL6cqb5/rQ57+gfHmJHDXFcPGtZ1UpVSYcQL+JkE TMoSb5XjOtVIGVvwpxFGIPEzZx33sORUZ6zKDeqrR3kFR8Ze/ZDXFUriQQfv4j78Fw/i Qv+NhhkVGHWXCEran49A4eJOH1NeSv2+/uqrPPzooSKjSFkV3AfwD5I01KKhJypix7Sd yzZnuMP81hipSHsPGpHF4KnZLcxwKHymTpeJkJGjk0wErqHdkMXoGLH3g72ZEYhBY7TG rR3RLfhyCt7PAmS6i7rt9fRpwIoAgShFTUB2nMNl8VAxRAXEFAZGQt0vX5RD91YqCtJU C24w== X-Forwarded-Encrypted: i=1; AJvYcCVIG4JiU4tg6qj14Q5g2siNYg01Czmaqz7BCLQpma/62tu2YnzyVaGOYLX3ac3lVV5fFqVSUfMg++kMM+eunCUFe7ME@freebsd.org X-Gm-Message-State: AOJu0YzisWIbIcC8Qdx566nHFVmeTQDoBh3v0pz1/K4aBD1r7dkkrsCP 7KpCt04gxgG6zr7+26Wv2HANnscpIC91qzehWKItG2X7oKKtQ5bMTwV/NlVmR3PoTkKS87quRbC HlMkZRjViDCDOucxZrIJSxsW65Q/X57Bx3502FcZ6KUwAvxou6tWieI8= X-Gm-Gg: AZuq6aIrPj0j+Rk9K/7l/kgY4ffVmmBlqqEmDx+9nbJVR0nbECjku87YcNZszbfF94b lOwKi1jSaRGQlR/vpO8Quo/DpyLcDv2as4KoRnTZYTLPkkkEaLbQPopueDYIHdMStAKJiTEFiZB QBdGPlo3nHV54P9q8fdJs643XS2bWX8XYsYQ5CvJW40ivKXFLwubdS40Op1jgMiS9OOTV58LVx9 AZ+guOmihW8pJHXsw/qK62RpIw9MjPjrZ6aQQHn18O9xAdD8T6bssMP4S3qyMbvIYjjmGWnvZrM F2KFPAQ= X-Received: by 2002:a17:90b:35c7:b0:356:2c7b:c013 with SMTP id 98e67ed59e1d1-35844fc83f5mr8578906a91.29.1771276603459; Mon, 16 Feb 2026 13:16:43 -0800 (PST) List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 References: <6991d07b.43f21.696cde4f@gitrepo.freebsd.org> <0B6A645E-D9E4-4337-B280-7E3CBA1FDC1B@freebsd.org> In-Reply-To: From: Warner Losh Date: Mon, 16 Feb 2026 14:16:30 -0700 X-Gm-Features: AaiRm52L-tKTtysf8z1JrzZA5d2Kv9vccHYioMiyirpFMTe7KOsu3FwL5U6l9Z4 Message-ID: Subject: Re: git: a60e7e6ff0ec - main - stand: compile ia32 EFI loader with -malign-double To: Ahmad Khalifa Cc: Jessica Clarke , "src-committers@freebsd.org" , "dev-commits-src-all@freebsd.org" , "dev-commits-src-main@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000bf9a2f064af77824" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4fFFvf4j3Nz47C9 X-Spamd-Bar: ---- --000000000000bf9a2f064af77824 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 16, 2026 at 1:30=E2=80=AFPM Ahmad Khalifa wrote: > On Mon Feb 16, 2026 at 3:29 AM +0200, Warner Losh wrote: > > On Sun, Feb 15, 2026 at 8:56=E2=80=AFAM Ahmad Khalifa > > > 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 > wrote: > >> >>> > >> >>> The branch main has been updated by vexeduxr: > >> >>> > >> >>> URL: > >> > https://cgit.FreeBSD.org/src/commit/?id=3Da60e7e6ff0ec1fdd66c2568ac6c03b8= 43dbb3c9d > >> >>> > >> >>> commit a60e7e6ff0ec1fdd66c2568ac6c03b843dbb3c9d > >> >>> Author: Ahmad Khalifa > >> >>> AuthorDate: 2026-02-15 12:23:26 +0000 > >> >>> Commit: Ahmad Khalifa > >> >>> 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 interna= l > >> >>>> 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 share= d > >> >> with libsa or the kernel itself that would change layout? (I suppos= e > >> >> 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 loade= r. > >> 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 th= en > > 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 > >> > >> > --000000000000bf9a2f064af77824 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Feb 16,= 2026 at 1:30=E2=80=AFPM 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=E2=80=AFAM Ahmad Khalifa <ahmadkhalifa570@gmail.co= m>
> 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@Free= BSD.org> wrote:
>> >>>
>> >>> The branch main has been updated by vexeduxr:
>> >>>
>> >>> URL:
>> https://c= git.FreeBSD.org/src/commit/?id=3Da60e7e6ff0ec1fdd66c2568ac6c03b843dbb3c9d
>> >>>
>> >>> commit a60e7e6ff0ec1fdd66c2568ac6c03b843dbb3c9d
>> >>> Author:=C2=A0 =C2=A0 =C2=A0Ahmad Khalifa <vexeduxr= @FreeBSD.org>
>> >>> AuthorDate: 2026-02-15 12:23:26 +0000
>> >>> Commit:=C2=A0 =C2=A0 =C2=A0Ahmad Khalifa <vexeduxr= @FreeBSD.org>
>> >>> CommitDate: 2026-02-15 13:30:06 +0000
>> >>>
>> >>>=C2=A0 =C2=A0 stand: compile ia32 EFI loader with -mal= ign-double
>> >>>
>> >>>=C2=A0 =C2=A0 The UEFI spec says:
>> >>>> Structures are aligned on boundaries equal to the= largest internal
>> >>>> datum of the structure and internal data are impl= icitly padded to
>> >>>> achieve natural alignment.
>> >>>
>> >>>=C2=A0 =C2=A0 By default, structs containing members o= f type "long long" have 4
>> byte
>> >>>=C2=A0 =C2=A0 alignment on i386. This caused some EFI = structures to be subtly
>> wrong.
>> >>>
>> >>>=C2=A0 =C2=A0 Fix this by compiling the ia32 EFI loade= r with -malign-double, which
>> >>>=C2=A0 =C2=A0 bumps the alignment up to 8 if such memb= ers are present.
>> >>
>> >> This seems like a dangerously big hammer. Are there any t= ypes shared
>> >> with libsa or the kernel itself that would change layout?= (I suppose
>> >> for the latter they already need to be aligned as the ker= nel 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 l= oader.
>> 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,<= br> > which has one calling convention and ABI (including structures), and t= hen
> it also lives in the world of creating some binary structs for the ker= nel.
> 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 th= e new
> conventions.

Yep, that's the problem I ran into. I'd rather we have a more elega= nt
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 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 UINT32 a;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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 c= onvention.
>> >
>> > They're all under contrib unfortunately. Not sure if we w= ant to
>> > introduce that big of a diff with upstream.
>> >
>> >>
>> >> Jessica
>>
>>
--000000000000bf9a2f064af77824--