[Mingw-w64-public] 64 bits cygwin gcc produces wrong constants with mingw win32 headers.
Hello, I've been following breadcrumbs now about that issue, and I finally ended up here. I have reported that issue already on msys2 and on cygwin (see https://github.com/Alexpux/MSYS2-packages/issues/555 and https://cygwin.com/ml/cygwin/2016-04/msg00379.html). The problem I see is that the w32api-headers package available on cygwin originates from mingw, and sometime will do the wrong thing when compiling a 64 bits cygwin binary that uses the win32 API, because in 64 bits, with cygwin gcc, sizeof(long) == 8. As an example of what I am talking about is the definition of FIONBIO in winsock2.h. Using cygwin's gcc, we end up with a value of 0x8008667e in 64 bits, whereas the correct value is 0x8004667e, because it's using sizeof(u_long) in its definition. Corinna Vinschen over in cygwin suggested that this might be something the mingw-w64 team might want to look at, possibly by replacing these definitions with sizeof(__ms_u_long): https://cygwin.com/ml/cygwin/2016-04/msg00383.html Thanks! -- Nicolas Noble -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Adding a new thread model to GCC
>>> If the current code assumes a struct and the Windows API calls need an >>> integer then either the existing code needs to be made more flexible, >>> or you need to define it as a struct and then convert to an integer >>> inside your new gthread wrapper functions. >> >> The Windows APIs involved use LARGE_INTEGER - a union of a 64-bit integer >> and an array of two 32-bit integers - because some languages might have no >> native 64-bit integer types. >> Actually in C99 and C++11 we just assume there is long long and int64_t >> despite the fact that ISO C marks int64_t as optional, so it can be regarded >> as a union whose only element is an int64_t. >> > What are the units of the argument? Milliseconds? >From Windows SDK: File Times A file time is a 64-bit value that represents the number of 100-nanosecond intervals that have elapsed since 12:00 A.M. January 1, 1601 Coordinated Universal Time (UTC). This decision makes it much easier to count leap years, no? > You have two choices, either modify all the places in libstdc++ that > use __gthread_time_t, changing the code to use some new function > template that populates a __gthread_time_t from a > std::chrono::time_point or std::chrono::duration, or define > a similar struct in your gthreads header and convert it to int64_t > inside your functions. For functions taking a relative time the > conversion from a { seconds, nanoseconds } struct to milliseconds is > trivial, for functions taking an absolute time you need to know the > epoch of the clock that was used when populating the struct. Will do that next week. Still need to make gcc work with my library. -- Best regards, lh_mouse 2016-04-18 -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Adding a new thread model to GCC
On 18 April 2016 at 10:57, Jonathan Wakely wrote: > On 18 April 2016 at 10:18, lh_mouse wrote: >>> I don't see why it has to be a struct, it just has to be suitable as >>> an argument to the relevant __gthread functions. >> >> The type __gthread_time_t is referenced in >> gcc/libstdc++-v3/include/std/mutex:157 >> __gthread_time_t __ts = { >> static_cast(__s.time_since_epoch().count()), >> static_cast(__ns.count()) >> }; >> This definition uses a braced-init-list that has two elements and is >> unsuitable for scalar types. > > Yes I know. > > What I meant is that there's no fundamental reason it needs to be a > struct. That code could be changed. However, that code in is only needed for timed mutexes, and I thought you said that wouldn't be supported. There is code using __gthread_time_t in that needs to work even if timed mutexes are not supported. -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Adding a new thread model to GCC
On 18 April 2016 at 10:18, lh_mouse wrote: >> I don't see why it has to be a struct, it just has to be suitable as >> an argument to the relevant __gthread functions. > > The type __gthread_time_t is referenced in > gcc/libstdc++-v3/include/std/mutex:157 > __gthread_time_t __ts = { > static_cast(__s.time_since_epoch().count()), > static_cast(__ns.count()) > }; > This definition uses a braced-init-list that has two elements and is > unsuitable for scalar types. Yes I know. What I meant is that there's no fundamental reason it needs to be a struct. That code could be changed. >> If the current code assumes a struct and the Windows API calls need an >> integer then either the existing code needs to be made more flexible, >> or you need to define it as a struct and then convert to an integer >> inside your new gthread wrapper functions. > > The Windows APIs involved use LARGE_INTEGER - a union of a 64-bit integer and > an array of two 32-bit integers - because some languages might have no native > 64-bit integer types. > Actually in C99 and C++11 we just assume there is long long and int64_t > despite the fact that ISO C marks int64_t as optional, so it can be regarded > as a union whose only element is an int64_t. What are the units of the argument? Milliseconds? You have two choices, either modify all the places in libstdc++ that use __gthread_time_t, changing the code to use some new function template that populates a __gthread_time_t from a std::chrono::time_point or std::chrono::duration, or define a similar struct in your gthreads header and convert it to int64_t inside your functions. For functions taking a relative time the conversion from a { seconds, nanoseconds } struct to milliseconds is trivial, for functions taking an absolute time you need to know the epoch of the clock that was used when populating the struct. -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Adding a new thread model to GCC
> I don't see why it has to be a struct, it just has to be suitable as > an argument to the relevant __gthread functions. The type __gthread_time_t is referenced in gcc/libstdc++-v3/include/std/mutex:157 __gthread_time_t __ts = { static_cast(__s.time_since_epoch().count()), static_cast(__ns.count()) }; This definition uses a braced-init-list that has two elements and is unsuitable for scalar types. > If the current code assumes a struct and the Windows API calls need an > integer then either the existing code needs to be made more flexible, > or you need to define it as a struct and then convert to an integer > inside your new gthread wrapper functions. The Windows APIs involved use LARGE_INTEGER - a union of a 64-bit integer and an array of two 32-bit integers - because some languages might have no native 64-bit integer types. Actually in C99 and C++11 we just assume there is long long and int64_t despite the fact that ISO C marks int64_t as optional, so it can be regarded as a union whose only element is an int64_t. > std::condition_variable::__clock_t must be a typedef for the clock > used by the underlying implementation, so it sounds like you should > use std::chrono::steady_clock for your thread model. > All conversions are done using the std::chrono facilities, before any > conversion to __gthread_time_t. That means the conversions are > portable. Thought so. I have to take a deep look. Thanks for your help! -- Best regards, lh_mouse 2016-04-18 -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Adding a new thread model to GCC
Oh I missed the build-in specs in gcc/config/i386/mingw32.h and it was lack of -lmcfgthread in it that caused the failure. Stage 1 seemed ok. Already hacked that. Rebuilding. Apologize for that. -- Best regards, lh_mouse 2016-04-18 - 发件人:Jonathan Wakely 发送日期:2016-04-18 16:59 收件人:lh_mouse 抄送:gcc,mingw-w64-public 主题:Re: Re: Adding a new thread model to GCC On 18 April 2016 at 08:39, lh_mouse wrote: > I have added a thread model and added its corresponding header files. But it > failed the linker. > > The file 'gcc/libgcc/config/i386/t-mingw-pthread' which contained two lines: > SHLIB_PTHREAD_CFLAG = -pthread > SHLIB_PTHREAD_LDFLAG = -Wl,-lpthread > > I copied the file to 'gcc/libgcc/config/i386/t-mingw-mcfgthread' and modified > the two lines to: > SHLIB_PTHREAD_CFLAG = -lmcfgthread > SHLIB_PTHREAD_LDFLAG = -Wl,-lmcfgthread > > It didn't work and I got a number of undefined references. The command line > that invoked the linker didn't include either option. > > How to solve this problem? What are the linker errors? When do they happen? -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Adding a new thread model to GCC
On 18 April 2016 at 08:39, lh_mouse wrote: > I have added a thread model and added its corresponding header files. But it > failed the linker. > > The file 'gcc/libgcc/config/i386/t-mingw-pthread' which contained two lines: > SHLIB_PTHREAD_CFLAG = -pthread > SHLIB_PTHREAD_LDFLAG = -Wl,-lpthread > > I copied the file to 'gcc/libgcc/config/i386/t-mingw-mcfgthread' and modified > the two lines to: > SHLIB_PTHREAD_CFLAG = -lmcfgthread > SHLIB_PTHREAD_LDFLAG = -Wl,-lmcfgthread > > It didn't work and I got a number of undefined references. The command line > that invoked the linker didn't include either option. > > How to solve this problem? What are the linker errors? When do they happen? -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Adding a new thread model to GCC
On 17 April 2016 at 17:56, lh_mouse wrote: > A glance over gthr.h reminds me __gthread_time_t. There seem few requirements > documented in gthr.h. > I discussed this with Adrien Nader on mingw-w64's mailing list a few days ago. > > Specifically, here are the two questions: > 0) Should __gthread_time_t be a struct or a plain integral type? > The 'struct timespec' used by pthread is a struct introduced in POSIX. > However my implementation uses a plain uint64_t. I don't see why it has to be a struct, it just has to be suitable as an argument to the relevant __gthread functions. If the current code assumes a struct and the Windows API calls need an integer then either the existing code needs to be made more flexible, or you need to define it as a struct and then convert to an integer inside your new gthread wrapper functions. > 1) How to obtain a __gthread_time_t representing the current time? > According to Linux man pages, the timeout parameter of > pthread_cond_timedwait() is the same as gettimeofday() - that is, it uses the > wall clock. > My implementation uses GetTickCount64() - that is, my implementation uses a > monotonic clock. std::condition_variable::__clock_t must be a typedef for the clock used by the underlying implementation, so it sounds like you should use std::chrono::steady_clock for your thread model. > Quoting from ISO/IEC WG21 Draft N4582 (C++1z): > [quote] > 30.4.1.3.1 Class timed_mutex [thread.timedmutex.class] > ... > template > bool try_lock_for(const chrono::duration& rel_time); > template > bool try_lock_until(const chrono::time_point& abs_time); > ... > [/quote] > the std::timed_mutex::try_lock_for() function template shall accept any clock > type, hence we have to do timestamp translation. It is also important to know > how libstdc++ handles this. All conversions are done using the std::chrono facilities, before any conversion to __gthread_time_t. That means the conversions are portable. -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Adding a new thread model to GCC
I have added a thread model and added its corresponding header files. But it failed the linker. The file 'gcc/libgcc/config/i386/t-mingw-pthread' which contained two lines: SHLIB_PTHREAD_CFLAG = -pthread SHLIB_PTHREAD_LDFLAG = -Wl,-lpthread I copied the file to 'gcc/libgcc/config/i386/t-mingw-mcfgthread' and modified the two lines to: SHLIB_PTHREAD_CFLAG = -lmcfgthread SHLIB_PTHREAD_LDFLAG = -Wl,-lmcfgthread It didn't work and I got a number of undefined references. The command line that invoked the linker didn't include either option. How to solve this problem? -- Best regards, lh_mouse 2016-04-18 -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public