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

[Nicolai Hähnle 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
>>> 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.