public inbox for [email protected]
help / color / mirror / Atom feedFrom: John Naylor <[email protected]>
To: Lukas Fittl <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Jakob Egger <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: Tobias Bussmann <[email protected]>
Cc: Andres Freund <[email protected]>
Subject: Re: Broken build on macOS (Universal / Intel): cpuid instruction not available
Date: Fri, 8 May 2026 10:48:55 +0700
Message-ID: <CANWCAZa5TEmjLy0xtBjP9NyuVCJpCOpVkBSzw-fqmH8D9tFzDg@mail.gmail.com> (raw)
In-Reply-To: <CAP53PkzLmeNUiNtcOyw62KkD7OzthdCbkwGTyAk+Lu3LKsmOcg@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<[email protected]>
<CAP53PkzLmeNUiNtcOyw62KkD7OzthdCbkwGTyAk+Lu3LKsmOcg@mail.gmail.com>
On Fri, May 8, 2026 at 12:34 AM Lukas Fittl <[email protected]> wrote:
>
> On Thu, May 7, 2026 at 9:22 AM Tom Lane <[email protected]> wrote:
> >
> > I wrote:
> > > ... The code in HEAD doesn't have
> > > that guard, and is essentially assuming that every x86 platform
> > > wil provide HAVE__GET_CPUID or HAVE__CPUID.
> >
> > Independently of whether macOS multi-arch is something we consider
> > supportable, I think the aforesaid assumption is a bad idea.
> > Can't we make pg_cpuid() return zeroes if it doesn't know how to
> > get the info, analogously to what pg_cpuid_subleaf() does?
Yeah, that seems like a good assumption to remove.
Jakob and Tobias, how far do you get with the attached, at least for
the target x86 case? And it might help if you sent the configure
output in a file so we can see what we're dealing with. Note also that
we have two build systems, since we'll likely transition away from
autotools:
https://wiki.postgresql.org/wiki/Meson
> Having worked in that area in this cycle, I think returning zeroes (or
> adding a return value that confirms we got data)
Speaking of return values, the TSC feature as committed doesn't
actually use the return value of pg_cpuid_subleaf(), but it seems like
something we could use someday. I don't see such a use for pg_cpuid()
beyond having zero values in the 4 variables.
> could work for the
> TSC related functionality, since we just fall back to the system clock
> and disallow TSC use if we can't get CPUID data. I'll let John confirm
> if there are any other optimizations that require CPUID data.
Yes there are, but everything should still fallback gracefully without it.
--
John Naylor
Amazon Web Services
Attachments:
[text/x-patch] dont-assume-cpuid-available.patch (534B, 2-dont-assume-cpuid-available.patch)
download | inline diff:
diff --git a/src/port/pg_cpu_x86.c b/src/port/pg_cpu_x86.c
index f22167da9af..f61f0940431 100644
--- a/src/port/pg_cpu_x86.c
+++ b/src/port/pg_cpu_x86.c
@@ -63,12 +63,11 @@ mask_available(uint32 value, uint32 mask)
static inline void
pg_cpuid(int leaf, unsigned int *reg)
{
+ memset(reg, 0, 4 * sizeof(unsigned int));
#if defined(HAVE__GET_CPUID)
__get_cpuid(leaf, ®[EAX], ®[EBX], ®[ECX], ®[EDX]);
#elif defined(HAVE__CPUID)
__cpuid((int *) reg, leaf);
-#else
-#error cpuid instruction not available
#endif
}
view thread (24+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Broken build on macOS (Universal / Intel): cpuid instruction not available
In-Reply-To: <CANWCAZa5TEmjLy0xtBjP9NyuVCJpCOpVkBSzw-fqmH8D9tFzDg@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox