[llvm-dev] OpenCL runtimes and LLVM command line options

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[llvm-dev] OpenCL runtimes and LLVM command line options

Dean Michael Berris via llvm-dev
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] OpenCL runtimes and LLVM command line options

Dean Michael Berris via llvm-dev
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
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>


--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] OpenCL runtimes and LLVM command line options

Dean Michael Berris via llvm-dev
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
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] OpenCL runtimes and LLVM command line options

Dean Michael Berris via 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
>>> [hidden email]
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
>>
>


--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] OpenCL runtimes and LLVM command line options

Dean Michael Berris via llvm-dev
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
>>>> [hidden email]
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>
>>>
>>
>
>

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev