Hi Alex,
JITLink came back onto the radar screen: we see that LLVM 20 will
deprecate the RuntimeDyld link layer that we're using. JITLink would
in fact fix the open bug report we have about LLVM crashing all over
the place on ARM[1], and I can see that would be quite easy to do what
you showed, but we can't use that solution for that problem because it
only works on LLVM 15+ (and maybe doesn't even support all the
architectures until later releases, I haven't followed the details).
So we'll probably finish up backporting that fix for RuntimeDyld,
which seems like it's going to work OK (thanks Anthonin, CCd, for
diagnosing that). That's all fine and good, but if my crystal ball is
operating correctly, fairly soon we'll have a situation where RHEL is
shipping versions that *only* support JITLink, while other distros are
still shipping versions that need RuntimeDyld because they don't yet
have JITLink or it is not mature enough yet for all architectures. So
we'll need to support both for a while. That's all fine, and I can
see that it's going to be pretty easy to do, it's mostly just
LLVMOrcCreateThis() or LLVMOrcCreateThat() with some #ifdef around it,
job done.
The question I have is: is someone looking into getting the C API we
need for that into the LLVM main branch (LLVM 20-to-be)? I guess I
would prefer to be able to use that, rather than adding more of our
own C++ wrapper code into our tree, if we can, and it seems like now
would be a good time to get ahead of that.
[1]
https://www.postgresql.org/message-id/flat/CAO6_Xqr63qj%3DSx7HY6ZiiQ6R_JbX%2B-p6sTPwDYwTWZjUmjsYBg%40mail.gmail.com
