From nobody Mon Feb 16 22:30:09 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 4fFHXX6sBMz6SRxT for ; Mon, 16 Feb 2026 22:30:20 +0000 (UTC) (envelope-from ahmadkhalifa570@gmail.com) Received: from mail-yw1-x1130.google.com (mail-yw1-x1130.google.com [IPv6:2607:f8b0:4864:20::1130]) (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 4fFHXX6MfWz3Jc2 for ; Mon, 16 Feb 2026 22:30:20 +0000 (UTC) (envelope-from ahmadkhalifa570@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x1130.google.com with SMTP id 00721157ae682-797d6f934e2so8582017b3.0 for ; Mon, 16 Feb 2026 14:30:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771281010; cv=none; d=google.com; s=arc-20240605; b=Ysqh1gbVAdH9twkLc9A4RfOjqNKYQeiuqQjaBKyCtUfo1g631KmCpDJfCzT3QPI+9m VUrUJVZ+q5noQwo+fTYQ22l5CzmRkJsZBkQhzOca9TkV2GFCeGDxlOUOsPHpizGaGhV6 17gBHTGGaNBO4CnQ8jn4qOilxX6S0gX6PgMPapzXJWdEtJNPQWvUNeQlBsPMCvOcq5TU m9vEZeRfrlpIUiRXHPITkU5uQWJ5kUK6QExQEV6lQ6yNfKKv/UBeOz23gTarIOQqJ0ID Z0G96QANZWYn/Nd6JYzTqP6ghrAMTMamJ6SZsh0b2W9JpUS0oF6iHDH+A2Prz4lhzOQJ U37w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:in-reply-to :references:from:mime-version:dkim-signature; bh=NvHin97A2SVVMFVcNpIJGiQsdfkOuVBZstF6AcjZvQs=; fh=ThpOKVoZXziELNyxd/cmk9vtGzI9SwCClIHdOp0jUek=; b=Pl6UlPswlkFqWhm4Ww6DaOHZIM1fFmQh9EOauPQAxVkKTJXN2Zb43jd8Sie8c5JMqM eNK2g/OAuSUPcxURDE+VFYncaKlhpnUsnoR/FrNTcqd3IMtQELrNU20CuGwV9B7gJac7 cdroJp/SMaUqSoASBrjjHgiQRomo6s/rMgFrrz0SCU2WutyEn41bQ9AKKVMyidlQOkhQ 7ElDxK/vmM7L+OCNwOcNzvqWNjo6ACMJjjXvK3f1qPYa5tiD88ymbMRQePeYto/5xfeM n+LXF2BIGP5mu0gx7M2Che6o2eBFtlX+8RHGYYm4wyFMn3trVTRGyc53e0cjWH/1nqf+ TPJQ==; darn=freebsd.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771281010; x=1771885810; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:in-reply-to :references:from:mime-version:from:to:cc:subject:date:message-id :reply-to; bh=NvHin97A2SVVMFVcNpIJGiQsdfkOuVBZstF6AcjZvQs=; b=Wi/X6/R+fS9wJGIYRiyp3dEIJ24fdwjvYYwuQhfHl7bIsDDYe+Vu8ZwSx/UYgnYRVo Nxnj79AHmOaq4/OO1pMh7qqvHzvb6CL/yUmfrAr+xN2amcla3LZP/C3OFxHkCvQGfr7g HwKIz+Dp57UObQQmPSoa1c/0nBU30yDB6YRgm78sOqCxOvsG20dPvOQMkiHHAsIHKcwJ IaW7hMVIVel5FHkJRxTPyr0xmJK/ZFnlgZ0kJa+Rt2hA+lViVN0vm0KpSU4f3AwxTPaI ysbV+Q7RcgN3x9O7gCOKKRu/qhZIZEcLrFfNytuPArlOgzZkxSH+6btfZauOz2xJn0eT qfzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771281010; x=1771885810; h=content-transfer-encoding:cc:to:subject:message-id:date:in-reply-to :references:from:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=NvHin97A2SVVMFVcNpIJGiQsdfkOuVBZstF6AcjZvQs=; b=IDZApuCHTMDlW41FYzj+Wsz9m/4L3f89Im0kkSBIbrgF/Uh+ojHJULUdV4FwDv+HiM /1jN1miD2gmpIOf6XnOHdcbgpiXzwyMxk9BzC8ZQx7Gsajcbr9VT6Zgg/lWNyS5qO3KU ka2sF7sOZG+EHIsWBziWtWdssEzdreuDQYL+N2iuZKa/7V6kjIwly5rma4NV5SR7i2rG WcMeQfYqSILJi/IfgRBYR4uEB65j33uGsxGX/cDsZdY7lP18R2q2M/00K1aTK2eLpgIR 0NZPQF8jpqTLuh97/Ry8oj+sxYDWYApM2rFa9vndtCoxc1cQ8yc4TDEnAaZxOxUB9HJa pJUA== X-Forwarded-Encrypted: i=1; AJvYcCUuyljbLxUELJTLwtugAKc/V7+gi5lrLEd72bNkHyviNgLoJXZWxLYnv6p8qioc1YIowaLmdwvF2WAAI9T82UIuOv9Q@freebsd.org X-Gm-Message-State: AOJu0YzYQlk+3N6kZRszkPj+hsxXUuIIkSJWbnIMhYLqJuC8Hbg4NRH1 srf3GJEv6lVOxnKkwJsK08nLW1+mGFi9ONVZGIPLLO5L0NYcyhNDei/iBhbs6v7DLSuGamuMVoZ jhRV/cUCXj/tbBW9jVGKWz1KO88JxnSY= X-Gm-Gg: AZuq6aKSr1kY68X39L6fUf2vGny2uPheB70bOjOasodbULAln3NFX2CrzsQL6sV2Hi4 1CWncKlUaY+cbUcDRTlGm+SkHfMcEQzP32rYQoUszRYLwGIVsuSTxyZGo6d8z26GgCRaYkgTzPy jkgLc9YZLyrs7hLwUCMM7BPL2Uj4stqQrlwFKE4PCyG7N2VboGSe8bSuNrj2v1xPOww9uOiIhBS XFX1iwSNwFG4BPxHoev4Bgdi03x5uTq6OH5PLNwf68TQ4NLyqnef28CCWJz1z5iKHzwR+Yc10+6 EM0VK3IEefChRI8zjsk= X-Received: by 2002:a05:690c:6285:b0:794:911a:a3ad with SMTP id 00721157ae682-797a0d31e7amr92100517b3.53.1771281010135; Mon, 16 Feb 2026 14:30:10 -0800 (PST) Received: from 490177373942 named unknown by gmailapi.google.com with HTTPREST; Mon, 16 Feb 2026 14:30:09 -0800 Received: from 490177373942 named unknown by gmailapi.google.com with HTTPREST; Mon, 16 Feb 2026 14:30:09 -0800 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 From: Ahmad Khalifa X-Mailer: aerc 0.21.0 References: <6991d07b.43f21.696cde4f@gitrepo.freebsd.org> <0B6A645E-D9E4-4337-B280-7E3CBA1FDC1B@freebsd.org> In-Reply-To: Date: Mon, 16 Feb 2026 14:30:09 -0800 X-Gm-Features: AaiRm50ZHIIF6HEaNthO1HBdBmeIcS5D6fb0M9YC_bPFJA0mUjFOjW8BxXQQ_0k Message-ID: Subject: Re: git: a60e7e6ff0ec - main - stand: compile ia32 EFI loader with -malign-double To: Warner Losh Cc: Jessica Clarke , "src-committers@freebsd.org" , "dev-commits-src-all@freebsd.org" , "dev-commits-src-main@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: 4fFHXX6MfWz3Jc2 X-Spamd-Bar: ---- On Mon Feb 16, 2026 at 11:16 PM +0200, Warner Losh wrote: > 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=3Da60e7e6ff0ec1fdd66c2568ac6c03b= 843dbb3c9d >> >> >>> >> >> >>> 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 intern= al >> >> >>>> datum of the structure and internal data are implicitly padded t= o >> >> >>>> achieve natural alignment. >> >> >>> >> >> >>> By default, structs containing members of type "long long" hav= e 4 >> >> byte >> >> >>> alignment on i386. This caused some EFI structures to be subtl= y >> >> 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 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 load= er. >> >> 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 t= hen >> > 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 ne= w >> > 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 recal= l > the details? The struct starts out like so: typedef struct { UINT32 Type; EFI_PHYSICAL_ADDRESS PhysicalStart; ... } EFI_MEMORY_DESCRIPTOR; EFI_PHYSICAL_ADDRESS is a UINT64, but Type doesn't get padded to an 8 byte boundry like it should be. > > >> 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 mak= e > 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. Yeah, that seems like the more sane way to do it. > > 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? In cases like the one mentioned above there would be a difference in layout. Although that would also be a concern for the BIOS loader, unless you're talking about something EFI specific. We do actually pass the framebuffer info struct (for both efifb and vbefb) to the kernel without specifying its alignment. AFAICT they just happen to align. Not sure what other oddities like that are lying around. > > Warner > > >> > >> > >> >> >> >> >> >> 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 >> >> >> >> >>