Different JITs and other clients of LLVM may have different needs in how symbol resolution should occur.
Details
Diff Detail
Event Timeline
I'm not actually sure I'm in favor of this but wanted another opinion.
To me DynamicLibrary::addPermanentLibrary doesn't really seem all that useful and actually complicates things a bit.
What is the reasoning of it existence?
If adding libraries with RTLD_LOCAL is important, could that not be accomplished with an additional argument to DynamicLibrary::getPermanentLibrary?
@marsupial, the reasoning for this is that we do not want to expose the symbols to our experiments software stacks because they have other uses of llvm. dlopening cling as libcling allows to hide symbols avoiding potential versioning and other issues.
We had this discussion in another review. The dlopen has to be outside, because DynamicLibrary::getPermanentLibrary symbol is not available until you call dlopen :)
lib/Support/DynamicLibrary.cpp | ||
---|---|---|
85 | I am a little confused by this section here. This seems well optimized for binaries which are statically linked. IIUC we disallow searching symbols from the dlopened from the process libraries? Why? |
lib/Support/DynamicLibrary.cpp | ||
---|---|---|
85 | Yes it's a bit uglier than needed...I can fix that. The point is ROOT seems to be the only user of addPermanentLibrary which is the only way to inject a handle of RTLD_LOCAL. As such searching the Process handle will in cases other than ROOT will have already searched all libs that are in Handles. Which means you've slowed things down for nonexistent symbols 2x for all users to accommodate your special needs. I can understand that you have a desire outside normal usage in LLVM but think it's better to have an argument to explicitly search any RTLD_LOCAL in Handles rather than require it for everyone. |
lib/Support/DynamicLibrary.cpp | ||
---|---|---|
85 |
Hm... It looks like you are arguing both ways here: you sold the initial version of the patch as 'improving' the situation for cling and its use-cases. Now you are essentially saying that you don't care if you broke it as this would slowdown 'hypothetical' users who resolve symbols from the process and have dlopened libraries. Oddly, I am not aware of any such complaints from those users as the previous version of the code was doing exactly this. Over the years ROOT has been one of the (if not the only) few use cases of this code path. We have extended this several times and your refactoring is breaking our use-case. To give you context: ROOT is used in many domains outside high-energy physics estimating over 10K users, excluding the CERN LHC program. |
lib/Support/DynamicLibrary.cpp | ||
---|---|---|
85 | Can we keep it civil? I'm offering a solution that will fix the problem for you, not at the cost for every other LLVM user and have merely asked for someone outside of ROOT to comment on the current situation. Other users of the JIT does symbol resolution this way and they also have users with tangible numbers. |
That looks very good. Can we add a test case with dlopening a library with RTLD_LOCAL.
I plan to test whether this patch is enough for us later this week.
I'd like to avoid adding the test at this moment.
I have subsequent patches to make DynamicLibrary a more usable class without adding them permanently.
In that is the ability to open with RTLD_LOCAL as well as tests for it.
include/llvm/Support/DynamicLibrary.h | ||
---|---|---|
96 | Did you mean "Search all loaded libraries as the SO_Linker would" ? |
include/llvm/Support/DynamicLibrary.h | ||
---|---|---|
96 | No, its what I think you are for. BTW, In case it wasn't clear: using this on Windows can cause real problems as a lot of C++ runtime can be exported via the binary (though I understand you want to preserve behavior ROOT has on Unix). |
include/llvm/Support/DynamicLibrary.h | ||
---|---|---|
96 |
My bad. I mis-parsed the sentence, maybe adding a comma would have helped me: "Search all loaded libraries, then as the SO_Linker would". Another point you might consider clarifying in the doc is whether the search of the libraries in SO_LoadedFirst and SO_LoadedLast is done in load order ('oldest first') or reverse load order ('newest first') [which is the closest to 'dependency order') |
Currently I am busy with other things and I would be able to test this beginning on July when I plan to upgrade LLVM again. Sorry...
@v.g.vassilev @pcanal :
Can you provide a concrete example of a test in ROOT that this patch does not solve?
@marsupial, thanks for this. With a little tweaking I can say it fixes our use case.
@lhames, that seems to address what we discussed on irc. This covers our use case.
Did you mean "Search all loaded libraries as the SO_Linker would" ?