llvm dev - May 2018 - OpenCL runtimes and LLVM command line options

Hello everyone,

A while back I hit an issue where the presence of multiple OpenCL runtimes 
on a single system triggered errors in libLLVM caused by redeclaring 
command line arguments [0]. There's been some discussion on the bug report
and
a pointer to a slightly older report, unrelated to OpenCL, but most likely 
about the same issue [1].

OpenCL uses an ICD loader library to abstract away the installed runtimes. 
That way, applications can link against the ICD loader instead of the actual 
runtimes, which makes it more portable. This does also allow distributions to 
ship support for all the various OpenCL runtimes out there.

The problem is that some OpenCL runtimes link libclangCodeGen statically 
(where the offending cli arguments are defined), and libLLVM dynamically.

The ICD loader has to load every runtime on the system in order to determine 
which one to use. When an affected runtime is loaded, it registers the cli 
arguments from the static libclangCodeGen in the dynamic libLLVM. If another 
runtime is loaded that tries to do the same, the check in libLLVM triggers and 
aborts program execution.

The practical effect that users see is, once multiple OpenCL runtimes are 
installed on one system any OpenCL-enabled application aborts on start with an 
LLVM error. Needless to say this is a less than desirable situation.

There are currently multiple workarounds for this problem, each with its own 
set of drawbacks. Debian decided to statically link libLLVM [2], OpenSUSE 
decided to build all clang libs also as shared libraries (using 
BUILD_SHARED_LIBS=ON) [3] and Red Hat has an open issue about it in their bug 
tracker [4].

Since this issue has been present for a rather long time without clear 
solution or recommendation for a workaround, I'd like to bring this some
more
attention in the hopes of fixing this.

Grs,
Heinz

[0] https://bugs.llvm.org/show_bug.cgi?id=30587
[1] https://bugs.llvm.org/show_bug.cgi?id=22952
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852746
[3] https://bugzilla.opensuse.org/show_bug.cgi?id=1065464
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1565659
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180506/aafac27c/attachment.sig>

We have a similar problem in Mesa's radeonsi driver. It would be great 
if command-line options could somehow be tied to an llvm::Context, for 
example.

There is an even worse problem when *different versions* of LLVM are 
loaded into the same process. This is basically guaranteed to lead to 
crashes because of symbol clashes. I wonder if C++11 inline namespaces 
could be used for proper versioning. I admit I haven't given it too much 
thought.

Cheers,
Nicolai

On 06.05.2018 13:05, Heinz Wiesinger via llvm-dev wrote:
> Hello everyone,
> 
> A while back I hit an issue where the presence of multiple OpenCL runtimes
> on a single system triggered errors in libLLVM caused by redeclaring
> command line arguments [0]. There's been some discussion on the bug
report and
> a pointer to a slightly older report, unrelated to OpenCL, but most likely
> about the same issue [1].
> 
> OpenCL uses an ICD loader library to abstract away the installed runtimes.
> That way, applications can link against the ICD loader instead of the
actual
> runtimes, which makes it more portable. This does also allow distributions
to
> ship support for all the various OpenCL runtimes out there.
> 
> The problem is that some OpenCL runtimes link libclangCodeGen statically
> (where the offending cli arguments are defined), and libLLVM dynamically.
> 
> The ICD loader has to load every runtime on the system in order to
determine
> which one to use. When an affected runtime is loaded, it registers the cli
> arguments from the static libclangCodeGen in the dynamic libLLVM. If
another
> runtime is loaded that tries to do the same, the check in libLLVM triggers
and
> aborts program execution.
> 
> The practical effect that users see is, once multiple OpenCL runtimes are
> installed on one system any OpenCL-enabled application aborts on start with
an
> LLVM error. Needless to say this is a less than desirable situation.
> 
> There are currently multiple workarounds for this problem, each with its
own
> set of drawbacks. Debian decided to statically link libLLVM [2], OpenSUSE
> decided to build all clang libs also as shared libraries (using
> BUILD_SHARED_LIBS=ON) [3] and Red Hat has an open issue about it in their
bug
> tracker [4].
> 
> Since this issue has been present for a rather long time without clear
> solution or recommendation for a workaround, I'd like to bring this
some more
> attention in the hopes of fixing this.
> 
> Grs,
> Heinz
> 
> [0] https://bugs.llvm.org/show_bug.cgi?id=30587
> [1] https://bugs.llvm.org/show_bug.cgi?id=22952
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852746
> [3] https://bugzilla.opensuse.org/show_bug.cgi?id=1065464
> [4] https://bugzilla.redhat.com/show_bug.cgi?id=1565659
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 

-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.

On 05/07/2018 12:28 AM, Nicolai Hähnle via llvm-dev
wrote:
> We have a similar problem in Mesa's radeonsi driver. It would be great
if command-line options could somehow be tied to an llvm::Context, for example.
> 
> There is an even worse problem when *different versions* of LLVM are loaded
into the same process. This is basically guaranteed to lead to crashes because
of symbol clashes. I wonder if C++11 inline namespaces could be used for proper
versioning. I admit I haven't given it too much thought.
> 
Does enabling symbol versioning in LLVM fix this?

-Tom
> Cheers,
> Nicolai
> 
> On 06.05.2018 13:05, Heinz Wiesinger via llvm-dev wrote:
>> Hello everyone,
>>
>> A while back I hit an issue where the presence of multiple OpenCL
runtimes
>> on a single system triggered errors in libLLVM caused by redeclaring
>> command line arguments [0]. There's been some discussion on the bug
report and
>> a pointer to a slightly older report, unrelated to OpenCL, but most
likely
>> about the same issue [1].
>>
>> OpenCL uses an ICD loader library to abstract away the installed
runtimes.
>> That way, applications can link against the ICD loader instead of the
actual
>> runtimes, which makes it more portable. This does also allow
distributions to
>> ship support for all the various OpenCL runtimes out there.
>>
>> The problem is that some OpenCL runtimes link libclangCodeGen
statically
>> (where the offending cli arguments are defined), and libLLVM
dynamically.
>>
>> The ICD loader has to load every runtime on the system in order to
determine
>> which one to use. When an affected runtime is loaded, it registers the
cli
>> arguments from the static libclangCodeGen in the dynamic libLLVM. If
another
>> runtime is loaded that tries to do the same, the check in libLLVM
triggers and
>> aborts program execution.
>>
>> The practical effect that users see is, once multiple OpenCL runtimes
are
>> installed on one system any OpenCL-enabled application aborts on start
with an
>> LLVM error. Needless to say this is a less than desirable situation.
>>
>> There are currently multiple workarounds for this problem, each with
its own
>> set of drawbacks. Debian decided to statically link libLLVM [2],
OpenSUSE
>> decided to build all clang libs also as shared libraries (using
>> BUILD_SHARED_LIBS=ON) [3] and Red Hat has an open issue about it in
their bug
>> tracker [4].
>>
>> Since this issue has been present for a rather long time without clear
>> solution or recommendation for a workaround, I'd like to bring this
some more
>> attention in the hopes of fixing this.
>>
>> Grs,
>> Heinz
>>
>> [0] https://bugs.llvm.org/show_bug.cgi?id=30587
>> [1] https://bugs.llvm.org/show_bug.cgi?id=22952
>> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852746
>> [3] https://bugzilla.opensuse.org/show_bug.cgi?id=1065464
>> [4] https://bugzilla.redhat.com/show_bug.cgi?id=1565659
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> 
>