Something about replacing winpthread: If mcfgthread is loaded as a dynamic library, everything is fine. Its DllMain() function gets a DLL_THREAD_DETACH notification upon thread exit, enabling cleanup of thread local storage.
However if you wish to link mcfgthread statically, there will be trouble: The linker must be aware that there is a TLS directory to enable the essential TLS callback since there is no DllMain() in an executable. TheTLS directory can be placed in standard startup files (crt\d.o) or an individual library but also must be refered in startup files, otherwise the linker would consider it unused and throw it away. __attribute__((__used__)) woundn't help, because it is the object file (.o) in the static library that will be ignored. This would require hacking the startup files too and might break the ABI. ------------------ Best regards, lh_mouse 2016-04-14 ------------------------------------------------------------- 发件人：Ruben Van Boxem <[email protected]> 发送日期：2016-04-14 18:17 收件人：[email protected] 抄送： 主题：Re: [Mingw-w64-public] Adding a new thread model to GCC I'd really really really suggest just using --enable-threads=windows or something, and implement them using somthing compatible to the windows runtime if at all possible. This is available on Windows 7+ and seems as reasonable as anything. If there are better routines in e.g. Windows 8 or 10, it would be better to make the decision at runtime if at all possible IMHO, so that newer GCC versions can also be extended without yet another ABI breaking change like this. But hey, I'm all for a new threading model. This would be a great opportunity to remove the winpthreads dependeny of C++11's std::thread implementation in libstdc++. Ruben 2016-04-14 12:12 GMT+02:00 Dongsheng Song <[email protected]>: > If we use --enable-threads=win32-win7 , the result gcc running on and > target to win7 or later looks reasonable. > > On Thu, Apr 14, 2016 at 2:34 PM, Martin Mitáš <[email protected]> wrote: > > > > > > Dne 14. 4. 2016 v 5:02 Dongsheng Song napsal(a): > >> Currently, --enable-threads=win32 map to gthr-win32.{h|c}, could we map > >> > >> --enable-threads=win32-vista > >> --enable-threads=win32-win7 // Windows 7 and Windows Server 2008 R2 > >> --enable-threads=win32-win8 // Windows 8 and Windows Server 2012 > >> --enable-threads=win32-win8.1 // Windows 8.1 and Windows Server 2012 R2 > >> --enable-threads=win32-win10 // Windows 10 and Windows Server 2016 > >> > >> to gthr-windows.{h|c} with the corresponding _WIN32_WINNT macros ? > > > > Please don't. > > > > Consider that something like -D_WIN32_WINNT=xy -DWINVER=_WIN32_WINNT > > is often used by projects to see newer Win32API structures and #defines, > > but the project often still supports older windows in run time. A lot > > of code out there plays with GetProcAddress() but doesn't want to > redefine > > all the new types and constants. > > > > Best regards, > > Martin > > > > > > ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
