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

[Tom Stellard 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
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>
>>>
>>
> 
>