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

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
>>
> 
>

On 07.05.2018 17:49, Tom Stellard wrote:
> 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?
*goes to check cmake*

Oh, you mean LLVM_DYLIB_SYMBOL_VERSIONING? That sounds plausible, but 
I've never tried it... why is that off by default?

Thanks,
Nicolai

> 
> -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
>>>
>>
>>
> 

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

On 05/08/2018 01:31 AM, Nicolai Hähnle wrote:
> On 07.05.2018 17:49, Tom Stellard wrote:
>> 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?
> 
> *goes to check cmake*
> 
> Oh, you mean LLVM_DYLIB_SYMBOL_VERSIONING? That sounds plausible, but
I've never tried it... why is that off by default?
> 
Symbol versioning should be enabled be default.  That option has been obsoleted,
so it shouldn't be necessary.

-Tom
> Thanks,
> Nicolai
> 
> 
>>
>> -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
>>>>
>>>
>>>
>>
> 
>