staticdata: remove reinit_ccallable

[aviatesk]

This commit removes jl_reinit_ccallable whose purpose is unclear.
Specifically, the function re-adds C-callable functions to the execution
engine during the loading of sysimages/pkgimages, but the consensus is
that the function is largely unnecessary because ccall can find
symbols via dlsym. The function's only apparent use case is a
contrived llvmcall example, only because we currently don't add the
sysimage symbols to the JIT, but we could do anyway. llvmcall has
always been experimental, and if it is truly needed, the functionality
for finding the symbols should be properly implemented later.

[vchuravy]

We might be missing test coverage, but I think PkgEval found this back then ...

Generally speaking a package that has a @ccallable and then a user who uses ccall to call it by name.

[gbaraldi]

I believe @topolarity touched this last, (I might be imagining it). But still we need this functionality. Otherwise what restores the ccallable pointer?

[vchuravy]

We have a test here

julia/test/precompile.jl

Line 261 in 3c7bc45

Base.@ccallable Cint f35014(x::Cint) = x+Cint(1)

&

julia/test/precompile.jl

Line 390 in 3c7bc45

@eval begin function ccallable_test()

And CI does complain: "JIT session error: Symbols not found: [ f35014 ]"

[vchuravy]

This code (or equivalent) is still needed as seen on CI.

[topolarity]

I believe @topolarity touched this last

Yeah, I was fixing a bug in this space in #55813 but I don't think it affects this PR much

[vtjnash]

Generally speaking a package that has a @ccallable and then a user who uses ccall to call it by name.

[vtjnash]

The test is for llvmcall, which is all experimental and can therefore just be deleted

[Keno]

Can you elaborate of what the difficulty of #56499 with jl_reinit_ccallable is? If we have a test for it that does raise the likelyhood that people are depending on it.

[vtjnash]

I fixed the test for CI, so that it uses the stable ccall interface instead of the unstable llvmcall one

[aviatesk]

@vchuravy We had a local discussion and reached a consensus that this functionality can be excluded without any issues. For detailed reasoning, please refer to the commit message. If there are no objections, I'd appreciate if you could remove the block. Thanks!

[vchuravy]

This breaks a feature I at least have used several times in research projects. I have used this to write self-hosted runtimes for Tapir and RMA based RPCs, which both had LLVM based interface and this feature allowed me to write those runtimes in Julia instead of C.

A related case is in GPUCompiler where we use a @ccallable + ccall("extern fn", llvmcall, ...) https://github.com/JuliaGPU/GPUCompiler.jl/blob/a9b5a8263e9bf1051395840b63b0c10fd503d8de/src/driver.jl#L137
This variant is also used by Enzyme.

So my objection stands.

[gbaraldi]

Should we use ORCs library handling to do this registering instead? I believe we can filter as needed i.e something like this

julia/src/jitlayers.cpp

Lines 2010 to 2022 in a23a6de

	if (libatomic) {
	static void *atomic_hdl = jl_load_dynamic_library(libatomic, JL_RTLD_LOCAL, 0);
	if (atomic_hdl != NULL) {
	GlobalJD.addGenerator(
	cantFail(orc::DynamicLibrarySearchGenerator::Load(
	libatomic,
	DL.getGlobalPrefix(),
	[&](const orc::SymbolStringPtr &S) {
	const char *const atomic_prefix = "__atomic_";
	return (*S).starts_with(atomic_prefix);
	})));
	}
	}

?