Re: [PATCH] jit: fix build with LLVM-21

From: Holger Hoffstätte <holger(at)applied-asynchrony(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] jit: fix build with LLVM-21
Date: 2025-09-12 07:47:23
Message-ID: b3376d7f-93b1-765d-addf-2e09939d0f47@applied-asynchrony.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2025-09-12 08:36, Peter Eisentraut wrote:
> On 08.09.25 15:20, Holger Hoffstätte wrote:
>> I tried building against LLVM-21 and noticed that a function for symbol
>> lookup was renamed (without semantic changes), breaking the LLVM JIT.
>> The following patch fixes this by adding a version guard. It applies equally
>> to both master and 17.6. Passes the test suite and verified on 17.6 with the
>> jit example from the documentation.
>
> I can confirm that this change seems correct.  See [0] for reference.

Excellent! Thanks for taking a look. This was my first post to pgsql-hackers
and I wasn't sure if I had done something wrong.

> [0]:
> https://github.com/llvm/llvm-project/commit/d3d856ad84698fa4ec66177d00558b2f5b438d3b
>
> As a small style request, I would flip the conditional around so
> that the new code appears first. I see that we don't do this very
> consistently in the existing code, but maybe we can start a new
> trend. ;-)
I knew this would come up since I pondered the same thing :D
As you said, the existing code is not consistent, but I can switch this
to let the new code appear first, if you prefer.
A new patch is attached.

> In my testing with LLVM 21, I'm getting an additional error:
>
> ../src/backend/jit/llvm/llvmjit_wrap.cpp:56:18: error: no matching constructor for initialization of 'llvm::orc::RTDyldObjectLinkingLayer'
>    56 |         return wrap(new llvm::orc::RTDyldObjectLinkingLayer(
>       |                         ^
>    57 |                 *unwrap(ES), [] { return std::make_unique<llvm::backport::SectionMemoryManager>(nullptr, true); }));
>       | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> /opt/homebrew/Cellar/llvm/21.1.0/include/llvm/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.h:58:3: note: candidate constructor not viable: no known conversion from '(lambda at ../src/backend/jit/llvm/llvmjit_wrap.cpp:57:16)' to 'GetMemoryManagerFunction' (aka 'unique_function<std::unique_ptr<RuntimeDyld::MemoryManager> (const MemoryBuffer &)>') for 2nd argument
>    58 |   RTDyldObjectLinkingLayer(ExecutionSession &ES,
>       |   ^
>    59 |                            GetMemoryManagerFunction GetMemoryManager);
>       | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> /opt/homebrew/Cellar/llvm/21.1.0/include/llvm/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.h:37:16: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 2 were provided
>    37 | class LLVM_ABI RTDyldObjectLinkingLayer
>       |                ^~~~~~~~~~~~~~~~~~~~~~~~
>
> I gather you're not seeing that?

I do not - I dropped the patch into my Gentoo package build for 17.6 and
it has been working fine when building with gcc-15.2 and the jit part
with clang-21.1.0. I also just rebuilt everything with clang-21.1.1 (no gcc)
and also do not see the problem. This is on amd64 Linux.

The following commit seems to be involved:
https://github.com/postgres/postgres/commit/9044fc1d45a0212fd123bd8f364eac058f60fed7

which is also in my 17.6 tree. I verified that the new
SectionMemoryManager.cpp is compiled without error.

Since you're using homebrew I guess this is triggered by the
__aarch64__ guard in src/include/jit/llvmjit_backport.h.

Unfortunately this is as far as I can help with this.
Please let me know if there is anything else I can do.

cheers
Holger

Attachment Content-Type Size
llvm-21-v2.patch text/x-patch 1.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2025-09-12 08:19:12 let ALTER COLUMN SET DATA TYPE cope with POLICY dependency
Previous Message Ashutosh Sharma 2025-09-12 07:37:46 Re: How can end users know the cause of LR slot sync delays?