From nobody Mon Feb 16 20:30:47 2026 X-Original-To: dev-commits-src-main@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 4fFDtw3PMQz6SJqf for ; Mon, 16 Feb 2026 20:31:04 +0000 (UTC) (envelope-from ahmadkhalifa570@gmail.com) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 4fFDtw1Qyhz42Xw for ; Mon, 16 Feb 2026 20:31:04 +0000 (UTC) (envelope-from ahmadkhalifa570@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-4375d4fb4d4so2925131f8f.0 for ; Mon, 16 Feb 2026 12:31:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771273858; cv=none; d=google.com; s=arc-20240605; b=DLHgPc6kSNuUkoC0LVBtFcrbK0dCYoFYrmKaC49mQKwsEC3OGvd9QHIP6/QI1MtbB+ 572n7FXGVREcf+TauV3zMnIWzZElCuudz+JjVyIWmImZkiy7J/p/SScLHMHG3xFrP8TI K4PPMRFfCmmuzMg7ys3DkyHLYaV6ks9/1V9lrV5NnCCVXqbu575mEruzo6ZsfMRJ9f1C xsnqPj5hPReMwk3OsuKjO97LlxOPU42rLxexOzCD7iwexQnlJ9ttbVPYv6QupxXReZw4 8tObKJWpgJzJ9+Vrv46ERF87raik6BRK9NAObv8l10+3B6RbF3pLJd0GlI8BXLDXE8Fg I+ow== 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=PepELcEoFIiUyF1oBoKh2KdPlkrXVEu2CncTY7edj64=; fh=9bMH/jhaF0dqX0tnnyjVhgv70TSzBFGy2NQ4qjyUyPs=; b=D1J+x+gKciycwAN53LiXjlthe4XBo+zDrW1Cpsc1WSndVQ5TuaJbCHI9kAKG8Ee480 +O1Xy9aMITqfJyRA2NqyZ9WhCbD8+zkBMKU6WhzLqqTQrtCUFGhNtWY86M+b02Z+hQmD +eLRv7vS7+w+YMIyInOoyYAB1yzDLOoemvbG9e6xSAaRPIbUAuCCBINZYdI+tTHEznGq 7AMQ8ElgDYybnGzW9XeyyWs1Okja0M97/m94ttVeWs/ScgN5kOkm5iUUyURiYtLVVcVo NbOw0Xf9F/oj0ThNe6+KHZV9DKyRVY5cR9l0rtW0S9Z8Ug9Xk5Tz35dbQSP09jtDg0BE OGwg==; 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=1771273858; x=1771878658; 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=PepELcEoFIiUyF1oBoKh2KdPlkrXVEu2CncTY7edj64=; b=O/fwjQX2q52EtpLfX4qjaP9Psa0NcmpcrPK4doHvPCLib6qd+rgpuHsdr82BQnNPI7 NCnHnpcyTqi2r55rJP5NblYmB541zJ3ClU6c7J0NrYgji7nksQ2B4KDS/eRE8JTzLvbo 7iaVNs/o7EmkrowMbk2kbrm0woVVlFAzdDZyKKK439xSZbDRxLKQDM4Ak2+K/AU1f0pL AVlxS++ILWWhLRMd+muD9puCI3oHgS+aiGDK+1Qi0iOUIlQxZ/IR6oNDp3P2/3PZ10Gu BdenAS2tPl0mhj35DRmutreteuVCFW12Kp/FzHpxmdhVIYEk+lN18XBpSF69pvRXLyD9 7yVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771273858; x=1771878658; 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=PepELcEoFIiUyF1oBoKh2KdPlkrXVEu2CncTY7edj64=; b=DWtRQAAFkIqTCja50lTbfpt3E5BMulIAYcMPLLfi5N0sJMCqCHhMw+0PmCRsltkplO VjY+/tJF8MM2IjRqQ+P9bZfwdJgj6AGXqX7n9qX34QKlF2A4DMo02MXNQWfVr7s11TSA PpS60IzQzxAs0ZeNzrCWpt5ANEIzwsw9LNGbYSbJiitwMj2NnMG6D20HGd16uwwDzEkj a6A7AfpgAT0W+ATQvWLiwveUXeBMwxUWhXtX6EjGaGCaPm1OIa7lv6Cmg75JpbKL8Fbc V1qHJJqk9vQNrTxHVMk3POamDN3CCQ+Znlv2YskmDYPPIiJW3aIDZu9ufR5ka7lolFtP RMJA== X-Forwarded-Encrypted: i=1; AJvYcCVVPc9ydN/utKCp+1oxdZJ4NmPOHm/dUeehvV967LNFPlZo/cQIqGuOskkjK5inQuvDP+ycx295FsjLSJYR+mMWUd4OeA==@freebsd.org X-Gm-Message-State: AOJu0YzhnhPpOt3lz64P3LVQl8/PiUrnt4QJ5KZm3zJb2r4n2Mx0ZGyi xN5p8J8Un6Sm6oSfWXbVOeHjqyTHHGUuNTjx/lYARLZrq1GyEl6OkbrKiAtmYpWV+u4RBLSXjvh eWaSEETMfBB2f47wfO6BDFI9owokxPaOemw== X-Gm-Gg: AZuq6aI6C5Da1Hfg4qZ1rmdVy//C6Sg9EfQKnKFAR8L/qGOoYaMlxnNH2q/7ajxuV+j yloEiqbsL74OyWkxpd6RdRaHcz2V9cah/bquXAqa8OGsXjb6jpzEOGl5iQmbBfDoM3Z/WCXyy4k 4d4Bmi5Jgz9GaKmY6o3hiG/cKVq9t0ihuwRD3wBegCRjucch40/+JlBLpi9eX+sPAh9gcpkH8GQ ArCrO6bKub5gEgCJElaTCS5VGf0W/q955Ly/fKqKvB9/9mNGgYMV3poHWb2Q5gByU5mZsgJ9V31 HRXexwp1 X-Received: by 2002:a5d:5f82:0:b0:437:6b73:ffb1 with SMTP id ffacd0b85a97d-4379790e752mr21209396f8f.30.1771273857748; Mon, 16 Feb 2026 12:30:57 -0800 (PST) Received: from 490177373942 named unknown by gmailapi.google.com with HTTPREST; Mon, 16 Feb 2026 12:30:47 -0800 Received: from 490177373942 named unknown by gmailapi.google.com with HTTPREST; Mon, 16 Feb 2026 12:30:47 -0800 List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@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 12:30:47 -0800 X-Gm-Features: AaiRm52xsaAxLnuZLRhFgxSjk3Iz41Im4hXy9iMRVKh9YFZC56BlzSt9Au7y8Eo 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:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4fFDtw1Qyhz42Xw X-Spamd-Bar: ---- 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 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, wh= ich >> >>> 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-bi= t?) >> > >> > For the kernel, any shared types would have already needed to be >> > aligned, yes. I didn't consider shared types with either libsa or libe= fi >> > 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 BIO= S > 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 w= e >> >> 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 >> >>