From nobody Mon Feb 16 01:29:05 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 4fDlYc60gKz6RqH3 for ; Mon, 16 Feb 2026 01:29:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 4fDlYc324cz3rdg for ; Mon, 16 Feb 2026 01:29:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x432.google.com with SMTP id d2e1a72fcca58-82491fbf02cso1552961b3a.1 for ; Sun, 15 Feb 2026 17:29:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771205357; cv=none; d=google.com; s=arc-20240605; b=FeZQjRTVrQeZfS9ueNsDsIxKbb4s8kDwr2m9vBMtYCdgKb18y32YTrqNrozo0LVh+j 4b5i/I9IMBQzxlo8iwdFH4C72uK1usnmlQaeS2VzCFhw9lWKs6KOUw+M/bPMg9dvcnw1 P066Y8IjSTFVZOgInJvkfOlzUaKxP/DpP8lFhY1yqz5sKWDr4z872OwwNVp5z5QPwGXp zTuFbSOYgXi88RmXsVq3ET95Ev40mZyDafrc7HS9rt/gFtH+VMUtbkpuB6DjE4SGU4rR NE7bjPchXLXgy8UPAMNvKk3eo22c5mC9qJPcb7Z6dnh4NuIsRXne1lqA52hHB+cEdRb9 03Wg== 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=pepB5p5va5hInw70eI+KOBapY/cJwwP0WP+Um9+KuhI=; fh=FoXSCrmnfR8G15TmMH2ZxWpjZToraiCnZ1b//kXwW8Y=; b=Ge9pY9JyCIoB6KSmfHzs18/JY+35QifFp5n9ctd1kiE/y6WxAi3WhhUO0XUaFHkTgX 2i1z6TT7kywJxHkyp8vYOxbP+DXpGneaDp8en0vwdKTw6OOyk3mvbuCKNVnVgVATmFuD dqW7mV51oV4UGPADCNFn2Mt0GFDiyymEHbmQ/nMZFa1ICXppBIe5Wp8ioCq9HVy9zuka Sz4YU65RS22BLj1gbxfS7NUrkWkog1t5/b1PhhEpxGvsyTfcHp4oFgHRn8r0cjHvIfnP 6S3YhdDVO3H4dXgRd2n42JHIClzujSlxxK8OJvTLy9VmUhNBXWovY6kfFCviT8RdqKHc J/Pw==; 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=1771205357; x=1771810157; 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=pepB5p5va5hInw70eI+KOBapY/cJwwP0WP+Um9+KuhI=; b=dgB3CrsZVLBFHSHHxpUovWeMdmayN3SoRo85XsrQOd38kJ3B5V2DHIYFf3ix2LYMCQ 4TJ33mNbJ1LGeYXGNseo9qT7Lwhxyr6uK37arJMDBSg+iJM+YnHyVQGe4x8ll7GvUfS9 oB0nXNje0j7rky635iRPtptN+3xrdACgBGRCQ6Y2GotrhPFtBt2a0DorAR62jv3/50/y KX4YJmaQ+CcBzOYRrQHp3yD3LLHKlCJRD7Np0AqblEFUfdV0oRGfcJHc61J2PZslD/kk VI/AwPf//4bDuySpZUDLYoEfQqCAmvmhTyX0rr4YPSW5WPZmevEvf+TY8VrdxRU/+eze rJNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771205357; x=1771810157; 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=pepB5p5va5hInw70eI+KOBapY/cJwwP0WP+Um9+KuhI=; b=Dm+6HHbLBdDk51RKlh35kR1MHuBK/8tkVLCFacKx0pDfZCPTX4z3n1Z/dz0azQVccS hDtJ+MOoVhTvOg4wU4nGckDO0ktzyox+kA0rsGRow/O8rW8J2lUvptHTyLy/Uuge6E9Y 9RRBIqbrM8nLl8+3MOBGf/7kJqDvr7WWC0Rcmb9rf28umSXNIc+ORkc4wtkKopYxG0y0 AIa/ioOraWNqQXcXlhE1+6aLktXSuDbPA6bDIpWO6yLHeQSS7OpZom2Pc5ZKldipn/KV TGAmXkthjYeuE6HMlvYc3pnDBBT8IdGzwcPSMHMtsVCMMIqFM4+KGjybuxjgOXMSPJ27 mwrw== X-Forwarded-Encrypted: i=1; AJvYcCU+TBdSUqTkfbslWWjx/7cveugy2uQC06zxiGz+rcJ6MFO7bs/dsoX6GUMdUpLn+ohAF7Os+4CGiL/3/56LzqSlKOIW@freebsd.org X-Gm-Message-State: AOJu0YwIA1cfZQlpvCZbxiaG6aOKmcLpSbpSl51b15HlTlnEaj8eIltE 5+73hsdTX3IFYh+9BPN0p0KQYoCf2VeXotrGd6xzMAPvnmJlG9p7pd4FV++eTKQEDm3SkPHm/Au ADDMiB6qjtYU+PeuVV0gMqagmYxMtK64wKpBr29F3m6SaXz2744jCqgc= X-Gm-Gg: AZuq6aKzFN7Fc6pmFmV7U3tYizFv3Q1BtJT14YpPw1sZXXdRbxCNTgxuAQ5r4pInVYp LYiBH4d5LX/peKt3+Zn/zshpB6C7f6u3q9+UfjHjwizkuNfrQuRN9EvuBVKCePD5D5Ai/1bGIP7 yzIvUjFKr01/+Zr/4bcE2T7vAMOjBN9ivPwstqmUM7liZP+5Cz0FMtYeCs9pTuRUtbkwmlIGHs8 E5yGyIqhDTHIkkow/kmF3GurjU2pWUCmzOly/qMrgDiaJuQvvWo9UoJv5UH7NUAj2348LPuQ5ZG KURwsZE= X-Received: by 2002:a05:6a20:160a:b0:364:be7:6fe9 with SMTP id adf61e73a8af0-394838f4811mr5597668637.32.1771205356951; Sun, 15 Feb 2026 17:29:16 -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: Sun, 15 Feb 2026 18:29:05 -0700 X-Gm-Features: AaiRm51-opNm9IwtGM16bTVSBAbAloWTQLmTJTv2B4FrxL5qt0Ve-S_p387dhws 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="000000000000202563064ae6e21c" 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: 4fDlYc324cz3rdg X-Spamd-Bar: ---- --000000000000202563064ae6e21c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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, whi= ch > >>> 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 libef= i > > 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. I'm curious, which structures does this affect. UEFI / EDK2 tries hard to make details like this not matter. > >> > >> 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 > > --000000000000202563064ae6e21c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Feb 15,= 2026 at 8:56=E2=80=AFAM 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&g= t; wrote:
>>>
>>> The branch main has been updated by vexeduxr:
>>>
>>> URL: = https://cgit.FreeBSD.org/src/commit/?id=3Da60e7e6ff0ec1fdd66c2568ac6c03b843= dbb3c9d
>>>
>>> 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 -malign-doubl= e
>>>
>>>=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 implicitly pa= dded to
>>>> achieve natural alignment.
>>>
>>>=C2=A0 =C2=A0 By default, structs containing members of type &q= uot;long long" have 4 byte
>>>=C2=A0 =C2=A0 alignment on i386. This caused some EFI structure= s to be subtly wrong.
>>>
>>>=C2=A0 =C2=A0 Fix this by compiling the ia32 EFI loader with -m= align-double, which
>>>=C2=A0 =C2=A0 bumps the alignment up to 8 if such members are p= resent.
>>
>> This seems like a dangerously big hammer. Are there any types shar= ed
>> with libsa or the kernel itself that would change layout? (I suppo= se
>> 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 ca= lling 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 wors= e, since the 32-bit loader code is also shared with the BIOS
load= er, which has some different layout conventions...

If we have to do this, we'd likely need another libsa32 etc for the ne= w conventions.

I'm curious, which structures d= oes this affect.=C2=A0UEFI / EDK2 tries hard to make details
like= this not matter.
=C2=A0
>>
>> Annotating just the EFI types would seem more appropriate, like ho= w 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

--000000000000202563064ae6e21c--