cglobal: Add an option to bypass jlplt mechanism #51108
Conversation
This adds an extra argument to `cglobal` to opt out of the jlplt runtime symbol resolution mechanism. This is necessary for StaticCompiler-like code that needs to function in environments that do not provide the julia runtime symbol resolution support code. Symbol resolution is deferred to the host linker (static or dynamic, where the latter may of course use its own PLT).
|
Is this so it can work without LLVM, or is the goal to allow for an even simpler runtime? |
|
This is for when you don't have the julia runtime at all. |
| if ((sym.f_lib && !((sym.f_lib == JL_EXE_LIBNAME) || | ||
| (sym.f_lib == JL_LIBJULIA_INTERNAL_DL_LIBNAME) || | ||
| (sym.f_lib == JL_LIBJULIA_DL_LIBNAME))) || sym.lib_expr) { | ||
| jl_printf(JL_STDERR,"WARNING: Attempted to use library expression for symbol %s while disabling jlplt. Library expression was ignored.\n", sym.f_name); |
There was a problem hiding this comment.
codegen shouldn't be printing, except when there is a bug in codegen
|
So instead of doing a dlopen it just emits a call to a symbol/load from a symbol? |
|
I don't really like the idea of a dynamic flag to control static behavior. LLVM does that sometimes (immarg or metadata), and it always looks like an implementation mistake to me whenever I see it (especially when I see them add an enum option that tells the optimizer that the immarg is actually a runtime value). In normal execution, this is handled by this optimization passes here: Line 1580 in 6f026e3 |
Would you prefer a codegen option instead? I think that could work and I'm moving into that direction anyway with some of the other static-ness restrictions. I don't think there's ever a situation where you want to mix and match jlplt and non-jlplt within the same function (though possibly within the same compilation unit). |
|
Having a codegen option seems probably to be fine. I am somewhat surprised now that the GPUCompiler folks hadn't already added that option, but I think they have been using a number of workarounds with "extern llvmcall". |
Alternative to #51108 with the same objectives.
|
Replaced by #51123 |
This adds an extra argument to
cglobalto opt out of the jlplt runtime symbol resolution mechanism. This is necessary for StaticCompiler-like code that needs to function in environments that do not provide the julia runtime symbol resolution support code. Symbol resolution is deferred to the host linker (static or dynamic, where the latter may of course use its own PLT).