From nobody Mon Feb 16 20:30:47 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 4fFDtw6Kd3z6SJsK for ; Mon, 16 Feb 2026 20:31:04 +0000 (UTC) (envelope-from ahmadkhalifa570@gmail.com) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 4fFDtw23qwz42gM 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-x431.google.com with SMTP id ffacd0b85a97d-4376acce52eso2304048f8f.1 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=Oa2n955gDLAsqDHzIxwDVJdcQsIMf/KTikEaEiKNbT5FKsyaNJwyxNFRgNK7Ptpif0 t96zmR3C4wXtI+xx88ZBr3b6DoYI1cYeH+h4kuTy4Xby05PdMg0GomREwhCh/43hDg/x gQHeDsGVWcCySbvHecNTqEco8ZlfnTLZ3dOWKVH0s4hQ++NvlojR9oor4vBw2MMhMS0R dh0inMkRgaf8OtwDAHWfuzV6C4U+0/nbgZY6lfNJFPkM2LVym0S4+qV98T1F6TxFl8CD 6ls1kF6NPk9oLPpQj+xGfhj7UBSR0L7Vak63axuzRt/hKbi2qF5Wo4ZRQlIOS1KGZKIk Tmcg== 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=AsldNkeDRF6o4J4ATg1GM1LNyxPam7FwSwnfHfPffAw=; b=KH+G9NxhEivyRS7ENIp1XB1oisFf+cRsPF1UgMDU5+2HSM3pGIeqjjvd2+khd3HFUP 2v987IabpVl8wV3H2LufqnpYKuATswq37Y/icG4YGAFpE38Hw0oqd1FZ1jjmXDp/Qmqv af7LCuSXv9A/oDkZqUwu+GtutHfjAaM3olXa5/arnNw03nyXttEu8sHmKTUoi5/0nM4j b+rmfg3s9OztkmX/tNP7bCC61MMR80iruVhCPnaOo8jNXaYjXJ3WcQSnj+buGIhxuTp2 gDZDHrXebMkdCJUi5ebJBhffY9oF4kpRzqKDIa9Uvihx9rveXxZrljCOD95lms8qLBQd FMUw==; 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=Ou7wSNoOq2EvZoBHVdQNKMtzszh52A8KkKhOHOFd4EJ2dbtJeM5XOXFE2uw+CRkJNn mWjCefYltGkOTrQcRXIFtcl04abMXyFUFB75l9A/cMOTKH7K8PmgD4Y4VTnoQ8ekVU8S EpDs3/seWFmelaJGhv/6rTjZZakg87Zoioo4EjYe1YNKvsdGfffaBZUXbJodgV75xZ26 Ip3v/RqNKwErt4EfS70XuP0qzF0guaVPg/qxsoAMd87PgOmyVlhC3R/BVslyQDdR8eko I5/aSW9RFZTc/hthPaB6GAZ5LHDcEqPLY1iYuIgkE/9623aWt0fAXf1uvfdELd38ataA WFmA== X-Forwarded-Encrypted: i=1; AJvYcCXgimP42G76WYGzg0NuuKg8E0dL0AuQthxc9W5+/NkRCTEk5g4EJkC/qLwiJH2T1M4Dq8fCDQ/T6SGdFsmpBFG12N08@freebsd.org X-Gm-Message-State: AOJu0YxywLx/amKVBlEjqMb8rE/d3uXiWCRHTIC10r6asCTUj35h1fMB iftbTUo3cnaUOinEDEI1QXfx0gGjFxXeDbMg5RVhJog5DCar2IzAHFRkn1IxmhIkiArEirl0MFN qWsuWu/qSetrkUW+Djb9iAE3r5gW5/Mw= X-Gm-Gg: AZuq6aKjwbvyPMLSV4U0rO2v3oXSQzAwslhbanZgMLqIQjOa14JkV3ZLm+lGBBXxkC9 ux6W4zMchGenDUURCDNaIse/8WMkoPJwM04dCAnHuUGLyHFCZ0N9oAX9Ji0GEXsauRzV7GxwidO 0xWEzwkpYDwWh0dFLN6WcUAARkZl0+CxHKao21EY59Glkqq8BlUL2mCDd11VEjfhQjlvrAdgVEE 5TrvpAVXGndGL3rUPNjTj483AiAsembO+d0zm9IkmBwO5yLFBjSKJQfUvF4UdGiTIrbxvyWqbp5 v5ogmJ8q 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 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 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: 4fFDtw23qwz42gM 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 >> >>