[NativeAOT] How do I receive a callback on library load in Linux?

[slxdy]

I'd like to have a DllMain, but on Linux.

Edit: I know the dangers of using DllMain in managed, but I understand what I'm doing. I'm already hooking into another thread, which allows me to use the System API either way.

[colejohnson66]

You should never do DllMain in managed code

[slxdy]

The GC is running on a separate thread, right? So as long as I don't make win32 api calls I should he fine, no?

[colejohnson66]

Maybe, but there's no guarantee. That's why the team has refused to support such a scenario. For example, even if you don't use P/Invoke, practically anything involving I/O will call into Win32. And things that don't use Win32 have no guarantee that they won't use it in the future. And it's not just Win32; anything involving P/Invoke could break, even internal calls to the runtime. As @jkotas said, they are "not interested in building features that are not 100% reliable."

Sure, if all your DllMain does is some computations and variable setting, you'll probably be fine. But, again, there's no guarantee about that.

The best thing you'll ever get is module initializers; Those are as close to a DllMain as you'll get, but they are safe.

[jkotas]

For example: I assume that your managed DllMain is the first managed code executed. It means that the prolog of the DllMain is going to initialize the runtime, the GC, etc. It will end up calling all this code:

runtime/src/coreclr/nativeaot/Bootstrap/main.cpp

Lines 182 to 203 in 57a2712

	if (!RhInitialize(
	#ifdef NATIVEAOT_DLL
	/* isDll */ true
	#else
	/* isDll */ false
	#endif
	))
	return -1;
	void * osModule = PalGetModuleHandleFromPointer((void*)&NATIVEAOT_ENTRYPOINT);
	// TODO: pass struct with parameters instead of the large signature of RhRegisterOSModule
	if (!RhRegisterOSModule(
	osModule,
	(void*)&__managedcode_a, (uint32_t)((char *)&__managedcode_z - (char*)&__managedcode_a),
	(void*)&__unbox_a, (uint32_t)((char *)&__unbox_z - (char*)&__unbox_a),
	(void **)&c_classlibFunctions, _countof(c_classlibFunctions)))
	{
	return -1;
	}
	InitializeModules(osModule, __modules_a, (int)((__modules_z - __modules_a)), (void **)&c_classlibFunctions, _countof(c_classlibFunctions));

. You can see there is a lot of Win32 calls, many of them are not safe for DllMain.

[slxdy]

But in that case, why does it never fail?

[jkotas]

The DllMain issues are effectively race conditions that repro intermittently and only when there is a bunch of other activity in the process.

If you have a simple (single threaded) test that just loads the library with DllMain, it will pretty much never fail.

[hez2010]

Check #66546

[slxdy]

Well yes, but thats the thing, I need an alternative for Linux

[jkotas]

The portable version are C++ global static constructor (or their low-level platform-specific mechanism - DllMain on Windows, https://stackoverflow.com/questions/39540364/does-static-initialization-and-or-other-code-get-run-when-dlopening on Linux and other ELF-based platforms, ...). You can create C++ file with global static constructor that calls back into your method, compile it to .obj/o, and link this .obj/o to your app. It comes with the same disclaimer as DllMain. It is not a reliable solution.

[slxdy]

Thanks! Since DllMain is already supported, any plans on adding support for the Linux alternative? Maybe a managed attribute that could be interpreted by the NativeAOT compiler?

[jkotas]

We are not interested in building features that are not 100% reliable.