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

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