Fork#41070: Please include libgccjit with MinGW GCC distribution
Open Date: 2020-12-23 17:28
Last Update: 2021-02-01 21:47
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/41070
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=41070
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2021-02-01 21:47 Updated by: keith
Comment:
Reply To davidmalcolm
Looking at the patches themselves:
23-libgccjit-win32-no-pthreads.patch(2KB)
- Patch to eliminate -lpthread dependency
@@ -2138,12 +2173,12 @@ void
playback::context::release_mutex ()
{
/* Release the big GCC mutex. */
JIT_LOG_SCOPE (get_logger ());
gcc_assert (active_playback_ctxt == this);
+ JIT_CONTEXT_RELEASE_LOCK (jit_mutex);
active_playback_ctxt = NULL;
- pthread_mutex_unlock (&jit_mutex);
}
Usage of "active_playback_ctxt" must be guarded by the mutex, so the JIT_CONTEXT_RELEASE_LOCK needs to be after the
active_playback_ctxt = NULL;
i.e. where the pthread_mutex_unlock call is.
Okay. A careless mistake on my part; thanks for pointing it out. I've fixed it, in my local build tree, and refreshed the attached patch.
Looking at the jit_mutex_initializer and the docs for https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-initializecriticalsection I see that InitializeCriticalSection needs to be called exactly once on a CRITICAL_SECTION.
Yes ... unless DeleteCriticalSection() is called before a subsequent initialization request, (but I can't see how that might be helpful here — we need the critical section to have been initialized, before we attempt to acquire the mutex, but behaviour is undefined if we call InitializeCriticalSection() on an already initialized section, or we attempt to delete an uninitialized one).
I see that the code does this via "static jit_mutex;" Presumably this leads to jit_mutex's ctor being called once when the DLL is loaded.
Yes.
Does this work correctly?
AFAIK, it does, but it's not a feature I use very often.
(I'm always a little nervous about global ctors; older toolchains don't always implement it reliably)
I wasn't completely sure, before I created my patch, so I wrote a toy program to test the concept:
#include <stdio.h> #include <winbase.h> #ifdef COMPILE_DLL extern "C" void jit_acquire_mutex( void ); extern "C" void jit_release_mutex( void ); static class jit_mutex_initializer { private: CRITICAL_SECTION mutex; public: jit_mutex_initializer(); void lock(); void unlock(); } jit_mutex; jit_mutex_initializer::jit_mutex_initializer() { InitializeCriticalSection (&mutex); printf ("jit_mutex initialized\n"); } void jit_mutex_initializer::lock() { EnterCriticalSection (&mutex); printf ("jit_mutex acquired\n"); } void jit_mutex_initializer::unlock() { LeaveCriticalSection (&mutex); printf ("jit_mutex released\n"); } void jit_acquire_mutex(){ jit_mutex.lock(); } void jit_release_mutex(){ jit_mutex.unlock(); } #else #include <unistd.h> int main() { HMODULE foo_dll; printf ("Loading JITFOO.DLL ...\n"); if ((foo_dll = LoadLibrary ("jitfoo.dll")) != NULL) { printf ("JITFOO.DLL loaded successfully\n"); typedef void (*hook)(void); hook acquire_mutex = (hook)(GetProcAddress (foo_dll, "jit_acquire_mutex")); hook release_mutex = (hook)(GetProcAddress (foo_dll, "jit_release_mutex")); printf ("Wait for JIT_MUTEX ...\n"); acquire_mutex(); printf ("JIT_MUTEX successfully acquired\n"); sleep (10); printf ("Relinquish JIT_MUTEX ...\n"); release_mutex(); printf ("JIT_MUTEX successfully released\n"); } return 0; } #endifWhen I compile, and run this under Wine, I see:
$ mingw32-g++ jitfoo.cc -o ~/VirtualBox/share/jitfoo.exe
$ mingw32-g++ -shared -D COMPILE_DLL jitfoo.cc -o ~/VirtualBox/share/jitfoo.dll
$ ~/VirtualBox/share/jitfoo.exe
Loading JITFOO.DLL ...
jit_mutex initialized
JITFOO.DLL loaded successfully
Wait for JIT_MUTEX ...
jit_mutex acquired
JIT_MUTEX successfully acquired
Relinquish JIT_MUTEX ...
jit_mutex released
JIT_MUTEX successfully released
Since I don't entirely trust the fidelity of tests run under Wine, I then ran the cross-compiled code on both a WinXP VM, and a Win7 VM; both reproduced identically the same output as Wine.
---------------------------------------------------------------------
Ticket Status:
Reporter: eliz
Owner: keith
Type: Feature Request
Status: Open [Owner assigned]
Priority: 5 - Medium
MileStone: (None)
Component: GCC
Severity: 5 - Medium
Resolution: None
---------------------------------------------------------------------
Ticket details:
ease add libgccjit to the binaries included in the MinGW GCC distributions.
This is required to be able to build projects that use libgccjit for JIT compilation of code.
One example of this is "gccemacs", a branch of GNU Emacs development (soon to land
on the master branch of Emacs) that compiles Emacs Lisp programs into native x86 code
for faster runtime performance.
Thank you.
--
Ticket information of MinGW - Minimalist GNU for Windows project
MinGW - Minimalist GNU for Windows Project is hosted on OSDN
Project URL: https://osdn.net/projects/mingw/
OSDN: https://osdn.net
URL for this Ticket:
https://osdn.net/projects/mingw/ticket/41070
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=41070