<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-12-16 14:50 GMT+01:00 Emil Velikov <span dir="ltr"><<a href="mailto:emil.l.velikov@gmail.com" target="_blank">emil.l.velikov@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">On 5 October 2016 at 23:12, Gustaw Smolarczyk <<a href="mailto:wielkiegie@gmail.com">wielkiegie@gmail.com</a>> wrote:<br>
> 2016-10-06 0:05 GMT+02:00 Emil Velikov <<a href="mailto:emil.l.velikov@gmail.com">emil.l.velikov@gmail.com</a>>:<br>
>> On 5 October 2016 at 21:45, Gustaw Smolarczyk <<a href="mailto:wielkiegie@gmail.com">wielkiegie@gmail.com</a>> wrote:<br>
>>> Hello,<br>
>>><br>
>>> I have encountered a following problem while trying to use radv<br>
>>> through LunarG's vulkan loader.<br>
>>><br>
>>> It seems that the loader dlopens() the ICD library twice. First, it<br>
>>> looks up "vk_<wbr>icdNegotiateLoaderICDInterface<wbr>Version" symbol, which<br>
>>> seems to be the new mechanism used to determine the version of ICD<br>
>>> interface. Since radv doesn't provide it, it fall backs to the older<br>
>>> scheme. Unfortunately, it seems that the loader first unloads the ICD<br>
>>> and then loads it again. That causes issues in LLVM libraries' command<br>
>>> line registration which happens while initializing global objects with<br>
>>> constructors. To be more specific, "asan-instrument-assembly"<br>
>>> registered in libLLVMX86AsmPrinter.so registers for the second time<br>
>>> and causes the following message:<br>
>>><br>
>>><br>
>>> $ vulkaninfo<br>
>>> ===========<br>
>>> VULKAN INFO<br>
>>> ===========<br>
>>><br>
>>> Vulkan API Version: 1.0.26<br>
>>><br>
>>><br>
>>> : CommandLine Error: Option 'asan-instrument-assembly' registered more<br>
>>> than once!<br>
>>> LLVM ERROR: inconsistency in registered CommandLine options<br>
>>><br>
>>> I have "fixed" the problem by manually removing<br>
>>> libLLVMX86AsmPrinter.so from the list of llvm dependencies to radv. It<br>
>>> seems that it was the only library registering any command line<br>
>>> option.<br>
>>><br>
>>> I am not sure who is to blame for this situation. It's possible that<br>
>>> advertising the new ICD entry point would fix it. LLVM is really<br>
>>> fragile about its command line registration framework. Last, the<br>
>>> vulkan loader could try not to unnecessarily dlclose and dlopen the<br>
>>> ICD library.<br>
>>><br>
>> From a quick read it sounds like something that should be fixed in<br>
>> LLVM. Namely: if a library sets up a state it should cleanup after<br>
>> itself.<br>
>><br>
>> That aside, does the radv vulkan driver have unresolved/undefined<br>
>> symbols (check via $ldd -r libvulkan_foo.so) with your workaround ? If<br>
>> not we {c,sh}ould drop the library from the link chain. Alternatively<br>
>> you can try static linking LLVM by using --disable-llvm-shared-libs at<br>
>> mesa configure time.<br>
><br>
> I see no relocation errors after doing ldd -r with my workaround.<br>
><br>
> I think the problem lays with how llvm-config is called. We enable<br>
> AMDGPU target and want the AsmPrinter module for it, so we enable<br>
> asmprinter component. However, this enables asmprinter for all enabled<br>
> targets. Since X86 target is enabled by default, this brings<br>
> X86AsmPrinter into the list of libraries.<br>
><br>
> llvmpipe/gallium need the X86 target, but radv could probably be built<br>
> without it.<br>
><br>
</div></div>Pardon for missing your reply here.<br>
<br>
In general I agree that one shouldn't link with libraries which they don't need.<br>
<br>
At the same time:<br>
 - a library is should tear down all the state that it sets up.<br>
Afaict the LLVM module sets it up "asan-instrument-assembly" thus it<br>
is the one responsible to unregister it.<br></blockquote><div><br></div><div>Yes, I also think this should be really fixed in LLVM. There is however an easy work-around for mesa that I have posted a few days ago [1].</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
 - Split shared LLVM wasn't a supported/recommended//good idea, last<br>
time I've heard.<br></blockquote><div><br></div><div>This is how llvm is built on gentoo by default [2]. Because of that it possibly affects all gentoo users.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Please use single LLVM shared lib or [separate] static LLVM libs.<br></blockquote><div><br></div><div>I will check what happens when I dlopen/dlclose/dlopen both separate and monolithic shared LLVM libraries.</div><div><br></div><div>Regards,</div><div>Gustaw</div><div> </div><div>[1] <a href="https://lists.freedesktop.org/archives/mesa-dev/2016-December/137277.html">https://lists.freedesktop.org/archives/mesa-dev/2016-December/137277.html</a></div><div>[2] <a href="https://github.com/gentoo/gentoo/blob/master/sys-devel/llvm/llvm-3.9.0-r1.ebuild#L270">https://github.com/gentoo/gentoo/blob/master/sys-devel/llvm/llvm-3.9.0-r1.ebuild#L270</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thanks<br>
<span class="gmail-HOEnZb"><font color="#888888">Emil<br>
</font></span></blockquote></div><br></div></div>