diff options
| author | Thomas Munro <tmunro@postgresql.org> | 2024-11-22 14:53:21 +1300 |
|---|---|---|
| committer | Thomas Munro <tmunro@postgresql.org> | 2024-11-22 15:29:47 +1300 |
| commit | 78c09bd9f94e8d9b5dc65ebcad4145e71381ce9d (patch) | |
| tree | fea16755e46e85a2016634c6ecbc9b9f203a6874 /configure.ac | |
| parent | c06e71d1acaf490660ed4ae5c28b3079628746b0 (diff) | |
| download | postgresql-78c09bd9f94e8d9b5dc65ebcad4145e71381ce9d.tar.gz postgresql-78c09bd9f94e8d9b5dc65ebcad4145e71381ce9d.zip | |
jit: Use -mno-outline-atomics for bitcode on ARM.
If the executable's .o files were produced by a compiler (probably gcc)
not using -moutline-atomics, and the corresponding .bc files were
produced by clang using -moutline-atomics (probably by default), then
the generated bitcode functions would have the target attribute
"+outline-atomics", and could fail at runtime when inlined. If the
target ISA at bitcode generation time was armv8-a (the most conservative
aarch64 target, no LSE), then LLVM IR atomic instructions would generate
calls to functions in libgcc.a or libclang_rt.*.a that switch between
LL/SC and faster LSE instructions depending on a runtime AT_HWCAP check.
Since the corresponding .o files didn't need those functions, they
wouldn't have been included in the executable, and resolution would
fail.
At least Debian and Ubuntu are known to ship gcc and clang compilers
that target armv8-a but differ on the use of outline atomics by default.
Fix, by suppressing the outline atomics attribute in bitcode explicitly.
Inline LL/SC instructions will be generated for atomic operations in
bitcode built for armv8-a. Only configure scripts are adjusted for now,
because the meson build system doesn't generate bitcode yet.
This doesn't seem to be a new phenomenon, so real cases of functions
using atomics that are inlined by JIT must be rare in the wild given how
long it took for a bug report to arrive. The reported case could be
reduced to:
postgres=# set jit_inline_above_cost = 0;
SET
postgres=# set jit_above_cost = 0;
SET
postgres=# select pg_last_wal_receive_lsn();
WARNING: failed to resolve name __aarch64_swp4_acq_rel
FATAL: fatal llvm error: Program used external function
'__aarch64_swp4_acq_rel' which could not be resolved!
The change doesn't affect non-ARM systems or later target ISAs.
Back-patch to all supported releases.
Reported-by: Alexander Kozhemyakin <a.kozhemyakin@postgrespro.ru>
Discussion: https://postgr.es/m/18610-37bf303f904fede3%40postgresql.org
Diffstat (limited to 'configure.ac')
| -rw-r--r-- | configure.ac | 7 |
1 files changed, 7 insertions, 0 deletions
diff --git a/configure.ac b/configure.ac index 82c5009e3e8..12136261347 100644 --- a/configure.ac +++ b/configure.ac @@ -633,6 +633,13 @@ if test "$with_llvm" = yes ; then PGAC_PROG_VARCC_VARFLAGS_OPT(CLANG, BITCODE_CFLAGS, [-fexcess-precision=standard]) PGAC_PROG_VARCXX_VARFLAGS_OPT(CLANGXX, BITCODE_CXXFLAGS, [-fexcess-precision=standard]) + # Ideally bitcode should perhaps match $CC's use, or not, of outline atomic + # functions, but for now we err on the side of suppressing them in bitcode, + # because we can't assume they're available at runtime. This affects aarch64 + # builds using the basic armv8-a ISA without LSE support. + PGAC_PROG_VARCXX_VARFLAGS_OPT(CLANG, BITCODE_CFLAGS, [-mno-outline-atomics]) + PGAC_PROG_VARCXX_VARFLAGS_OPT(CLANG, BITCODE_CXXFLAGS, [-mno-outline-atomics]) + NOT_THE_CFLAGS="" PGAC_PROG_VARCC_VARFLAGS_OPT(CLANG, NOT_THE_CFLAGS, [-Wunused-command-line-argument]) if test -n "$NOT_THE_CFLAGS"; then |