On Sunday 05 January 2025 01:25:02 LIU Hao wrote: > 在 2025-01-05 01:02, Pali Rohár 写道: > > Hello, > > > > Do you know that is the purpose of __native_startup_state and > > __native_startup_lock variables used in __tmainCRTStartup() static > > function which is called only from the EXE application entry point? > > > > I tried to find some documentation, but there is nothing neither on > > Microsoft webpage and neither in gcc or mingw projects. > > > > It looks like that __native_startup_lock is some synchronization which > > prevents nested execution of __tmainCRTStartup() function. But it is > > even possible? > > Here is a verbatim copy of relevant comments and declarations from > 'C:\Program Files\Microsoft Visual > Studio\2022\Community\VC\Tools\MSVC\14.43.34618\crt\src\vcruntime\vcstartup_internal.h' > which is freely installable with Visual Studio 2022: > > > // When the CRT DLL is used, we must synchronize access to the startup > code path. > // When all modules loaded in the process are native, there is no > opportunity for > // problems here. Managed module startup may cause unexpected reentrancy > into > // the startup code path if something goes wrong. These "locks" are used > to > // accurately test for those problems. > extern "C" bool __cdecl __scrt_acquire_startup_lock(); > extern "C" void __cdecl __scrt_release_startup_lock(bool is_nested); > > > These functions are out-of-line variants that do similar stuff to what you > quoted.
But the mentioned comment applies also for the main application EXE module? Or only for DLL libraries? Because I have feeling that only for DLL libraries... I can imagine that the EXE application depends on managed DLL library and somehow for that DLL library is startup code executed more times (maybe in parallel) when loader lock is not held. Also those functions are called from _CRT_INIT() function, available only when building DLL libraries, which DLL library has to call if using custom entry point. And I can imagine that DLL library may postpone execution of that function until the first call to the library is done (e.g. for optimization). So in this case the loaded lock is not held and multiple threads could call _CRT_INIT in parallel. So this should be guarded. But IIRC DLL library has no way to cause execution of main EXE application entry point. LoadLibrary does not call entry point for EXE binaries if for some reason dll library hook in some DllMain do that. And I'm not aware of any WinAPI function which is doing to call EXE entry point. The only known option is when process starts execution. And I highly double that CLR/.net is going to explicitly execute entry point of EXE application file for some case. It is just a big mystery for me what is the code path which can trigger this for EXE applications. _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
