ORC error: No callback manager available

Project Infrastructure LLVM Dev List Archives
1

Hi LLVM Developers,

I have a query about an LLVM error message that I'm encountering and I
hope it's appropriate to post to this mailing list about it.

Postgres can be built with LLVM-based JIT support.
I find that when running on Linux (RHEL8) on IBM Z hardware, using
LLVM8+, I'm seeing many instances of the following LLVM error message
appearing in the Postgres server log:

    ORC error: No callback manager available for s390x-ibm-linux

(strangely, it otherwise doesn't seem to be causing any problems)

Looking through the LLVM source code, it appears that for the
"systemz" architecture, there is currently no local CCMgr
implementation available, and this then prevents indirection support
and COD layer support. BUT - apparently it can still function (maybe
less efficiently?) without these?
Is somebody able to clarify exactly what that error message means and
what the limitations are? Is it unwise to use LLVM on architectures on
which this error is reported?
I looked through the LLVM V10 source code and there still seems to be
this issue for systemz.

Secondly, LLVM sends this error message to standard error. As a caller
of the LLVM library, it would be nice to be able to redirect such
messages from the library - is it possible?

Hope you can advise,
Greg

2

+Lang Hames, Lord of ORCs

3

Hi,

Any update on this? Anyone?

Greg

4

Hi Greg,

Thanks for your patience.

Looking through the LLVM source code, it appears that for the
“systemz” architecture, there is currently no local CCMgr
implementation available, and this then prevents indirection support
and COD layer support. BUT - apparently it can still function (maybe
less efficiently?) without these?
Is somebody able to clarify exactly what that error message means and
what the limitations are? Is it unwise to use LLVM on architectures on
which this error is reported?
I looked through the LLVM V10 source code and there still seems to be
this issue for systemz.

You are correct: The error is generated when a call is made to the createLocalCompileCallbackManager function. Platforms that don’t support a callback manager (yet) can not use lazy compilation, but can still JIT whole modules.

I suspect that postgres is using the older ORC C bindings. These always try to enable lazy compilation support and direct any errors to stderr. Postgress probably isn’t using the lazy compilation support anyway, which is why everything works just fine despite the error.

These older APIs are deprecated, so the best solution would be for postgres to move to the newer C APIs (see https://github.com/llvm/llvm-project/blob/master/llvm/include/llvm-c/Orc.h).

Are you working on Postgres yourself, or just building it?

Regards,
Lang.

5

Hi Lang,

Thanks for your reply.
I work on a product that is largely based on Postgres but we do
contribute the odd fix/improvement/feature to the open-source Postgres
where we can.

It seems to me that the newer ORC APIs only exist in LLVM10.
Were the older ORC APIs deprecated in LLVM10 only?
Unfortunately our product has a dependency on LLVM8 (e.g. on RHEL8 on
the systemz platform, the default LLVM version installed by the system
package manager "yum" is version 8).
For LLVM8, is there any other API that can be used to avoid the LLVM
"No callback manager available" error seen on systemz?

Regards,
Greg

6

Hi Greg,

Unfortunately there is no API to avoid the error message. The only way to avoid it would be to patch LLVM 8. The patch itself is simple: On OrcCBindingsStack.h line 455 (See https://github.com/llvm/llvm-project/blob/89de0d8dfbb9a6ff1f8b141ed70b563ecc094878/llvm/lib/ExecutionEngine/Orc/OrcCBindingsStack.h#L455) you just need to replace

logAllUnhandledErrors(CCMgr.takeError(), errs(), "ORC error: ");

with

consumeError(CCMgr.takeError());

It seems to me that the newer ORC APIs only exist in LLVM10. Were the older ORC APIs deprecated in LLVM10 only?

Yes. The old APIs were deprecated in 10 and will remain deprecated (but present) in LLVM 11. I aim to remove them before LLVM 12.

Regards,
Lang.