[Mingw-w64-public] discrepancy between MinGW32 and MinGW-w64 winbase.h (Interlocked API)
For 32 bit, the current MinGW-w64 winbase has: LONG InterlockedIncrement(LONG volatile *lpAddend); LONG InterlockedDecrement(LONG volatile *lpAddend); LONG InterlockedExchange(LONG volatile *Target,LONG Value); However, MinGW32 uses: LONG WINAPI InterlockedDecrement(LONG volatile *); LONG WINAPI InterlockedExchange(LONG volatile *,LONG); LONG WINAPI InterlockedIncrement(LONG volatile *); The lack of WINAPI qualifier in MinGW-w64 results in MinGW-w64 32 bit objects lacking the __stdcall decoration (eg. '_interlockedexcha...@8'), which means that a 32 bit MinGW-w64 generated library using any of the Interlocked calls above cannot be used with MinGW32 environment. You might also want to note the following from the MinGW32 header regarding the Interlocked API section: /* CAREFUL: These are exported from ntoskrnl.exe and declared in winddk.h as __fastcall functions, but are exported from kernel32.dll as __stdcall */ Regards, /Pete -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] discrepancy between MinGW32 and MinGW-w64 winbase.h (Interlocked API)
2010/8/17 Pete Batard pbat...@gmail.com: For 32 bit, the current MinGW-w64 winbase has: LONG InterlockedIncrement(LONG volatile *lpAddend); LONG InterlockedDecrement(LONG volatile *lpAddend); LONG InterlockedExchange(LONG volatile *Target,LONG Value); However, MinGW32 uses: LONG WINAPI InterlockedDecrement(LONG volatile *); LONG WINAPI InterlockedExchange(LONG volatile *,LONG); LONG WINAPI InterlockedIncrement(LONG volatile *); The lack of WINAPI qualifier in MinGW-w64 results in MinGW-w64 32 bit objects lacking the __stdcall decoration (eg. '_interlockedexcha...@8'), which means that a 32 bit MinGW-w64 generated library using any of the Interlocked calls above cannot be used with MinGW32 environment. You might also want to note the following from the MinGW32 header regarding the Interlocked API section: /* CAREFUL: These are exported from ntoskrnl.exe and declared in winddk.h as __fastcall functions, but are exported from kernel32.dll as __stdcall */ Regards, /Pete Thank you Pete for noticing that. We are aware of this and we solved things here a bit different, but maybe we could add here the stdcall decoration, too. Our Interlocked API is treated in our libmingwex and has here (as intrinsic) the __cdecl decoration. Therefore it shouldn't produce for you in general issues. Do you have here found issues while building? Regards, Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] discrepancy between MinGW32 and MinGW-w64 winbase.h (Interlocked API)
On Tue, Aug 17, 2010 at 2:24 PM, Kai Tietz ktiet...@googlemail.com wrote: 2010/8/17 Pete Batard pbat...@gmail.com: For 32 bit, the current MinGW-w64 winbase has: LONG InterlockedIncrement(LONG volatile *lpAddend); LONG InterlockedDecrement(LONG volatile *lpAddend); LONG InterlockedExchange(LONG volatile *Target,LONG Value); However, MinGW32 uses: LONG WINAPI InterlockedDecrement(LONG volatile *); LONG WINAPI InterlockedExchange(LONG volatile *,LONG); LONG WINAPI InterlockedIncrement(LONG volatile *); The lack of WINAPI qualifier in MinGW-w64 results in MinGW-w64 32 bit objects lacking the __stdcall decoration (eg. '_interlockedexcha...@8'), which means that a 32 bit MinGW-w64 generated library using any of the Interlocked calls above cannot be used with MinGW32 environment. You might also want to note the following from the MinGW32 header regarding the Interlocked API section: /* CAREFUL: These are exported from ntoskrnl.exe and declared in winddk.h as __fastcall functions, but are exported from kernel32.dll as __stdcall */ Regards, /Pete Thank you Pete for noticing that. We are aware of this and we solved things here a bit different, but AFAIR, they aren't specifically marked as WINAPI in ms headers (well, maybe their mistake?..) maybe we could add here the stdcall decoration, too. Our Interlocked API is treated in our libmingwex and has here (as intrinsic) the __cdecl decoration. If we change into __stdcall we will be doing an api change within ourselves. This needs careful adjustments Therefore it shouldn't produce for you in general issues. Do you have here found issues while building? Regards, Kai -- Ozkan -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] discrepancy between MinGW32 and MinGW-w64 winbase.h (Interlocked API)
2010/8/17 Ozkan Sezer seze...@gmail.com: On Tue, Aug 17, 2010 at 2:24 PM, Kai Tietz ktiet...@googlemail.com wrote: 2010/8/17 Pete Batard pbat...@gmail.com: For 32 bit, the current MinGW-w64 winbase has: LONG InterlockedIncrement(LONG volatile *lpAddend); LONG InterlockedDecrement(LONG volatile *lpAddend); LONG InterlockedExchange(LONG volatile *Target,LONG Value); However, MinGW32 uses: LONG WINAPI InterlockedDecrement(LONG volatile *); LONG WINAPI InterlockedExchange(LONG volatile *,LONG); LONG WINAPI InterlockedIncrement(LONG volatile *); The lack of WINAPI qualifier in MinGW-w64 results in MinGW-w64 32 bit objects lacking the __stdcall decoration (eg. '_interlockedexcha...@8'), which means that a 32 bit MinGW-w64 generated library using any of the Interlocked calls above cannot be used with MinGW32 environment. You might also want to note the following from the MinGW32 header regarding the Interlocked API section: /* CAREFUL: These are exported from ntoskrnl.exe and declared in winddk.h as __fastcall functions, but are exported from kernel32.dll as __stdcall */ Regards, /Pete Thank you Pete for noticing that. We are aware of this and we solved things here a bit different, but AFAIR, they aren't specifically marked as WINAPI in ms headers (well, maybe their mistake?..) This isn't a mistake AFAIK. It is caused by the fact that the Interlocked-API is for VC an intrinsic and in general intrinsics have __decl calling convention (or special like __chkstk). That kernel32 exports it as WINAPI is here caused by that fact that all functions exported by kernel32 (and other OS platform DLLs) are using __stdcall for 32-bit. maybe we could add here the stdcall decoration, too. Our Interlocked API is treated in our libmingwex and has here (as intrinsic) the __cdecl decoration. If we change into __stdcall we will be doing an api change within ourselves. This needs careful adjustments Right, I am not sure if this is really the right way to go here. Therefore it shouldn't produce for you in general issues. Do you have here found issues while building? Regards, Kai -- Ozkan Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] discrepancy between MinGW32 and MinGW-w64 winbase.h (Interlocked API)
On Tue, Aug 17, 2010 at 2:34 PM, Kai Tietz ktiet...@googlemail.com wrote: 2010/8/17 Ozkan Sezer seze...@gmail.com: On Tue, Aug 17, 2010 at 2:24 PM, Kai Tietz ktiet...@googlemail.com wrote: 2010/8/17 Pete Batard pbat...@gmail.com: For 32 bit, the current MinGW-w64 winbase has: LONG InterlockedIncrement(LONG volatile *lpAddend); LONG InterlockedDecrement(LONG volatile *lpAddend); LONG InterlockedExchange(LONG volatile *Target,LONG Value); However, MinGW32 uses: LONG WINAPI InterlockedDecrement(LONG volatile *); LONG WINAPI InterlockedExchange(LONG volatile *,LONG); LONG WINAPI InterlockedIncrement(LONG volatile *); The lack of WINAPI qualifier in MinGW-w64 results in MinGW-w64 32 bit objects lacking the __stdcall decoration (eg. '_interlockedexcha...@8'), which means that a 32 bit MinGW-w64 generated library using any of the Interlocked calls above cannot be used with MinGW32 environment. You might also want to note the following from the MinGW32 header regarding the Interlocked API section: /* CAREFUL: These are exported from ntoskrnl.exe and declared in winddk.h as __fastcall functions, but are exported from kernel32.dll as __stdcall */ This can't be good at all Regards, /Pete Thank you Pete for noticing that. We are aware of this and we solved things here a bit different, but AFAIR, they aren't specifically marked as WINAPI in ms headers (well, maybe their mistake?..) This isn't a mistake AFAIK. It is caused by the fact that the OK correcting myself, they are certainly marked as WINAPI by MS for x86 versions Interlocked-API is for VC an intrinsic and in general intrinsics have __decl calling convention (or special like __chkstk). That kernel32 exports it as WINAPI is here caused by that fact that all functions exported by kernel32 (and other OS platform DLLs) are using __stdcall for 32-bit. maybe we could add here the stdcall decoration, too. Our Interlocked API is treated in our libmingwex and has here (as intrinsic) the __cdecl decoration. If we change into __stdcall we will be doing an api change within ourselves. This needs careful adjustments Right, I am not sure if this is really the right way to go here. Therefore it shouldn't produce for you in general issues. Do you have here found issues while building? Regards, Kai -- Ozkan Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination -- Ozkan -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] discrepancy between MinGW32 and MinGW-w64 winbase.h (Interlocked API)
On 2010.08.17 12:29, Ozkan Sezer wrote: Thank you Pete for noticing that. We are aware of this and we solved things here a bit different, but AFAIR, they aren't specifically marked as WINAPI in ms headers (well, maybe their mistake?..) Well, the thing is that the MSDN documentation has __cdecl [1], but looking at WinBase.h from a Visual Studio 2008 installation, there's a definite WINAPI qualifier on 32 bit. So there's some conflicting data there... I would think that if both MinGW32 and VS's WinBase.h use WINAPI on 32 bit, MinGW-w64 probably wants to follow suit maybe we could add here the stdcall decoration, too. Our Interlocked API is treated in our libmingwex and has here (as intrinsic) the __cdecl decoration. Therefore it shouldn't produce for you in general issues. Do you have here found issues while building? I'm afraid we have. When compiling libusb 1.0 in a multilib MinGW-w64 environment, we found that the resulting 32 bit library was unusable in MinGW32 [2]. Looking at it more closely, we found that the pure MinGW32 binary had '_interlockedexcha...@8' (= __stdcall decoration) whereas the -m32 MinGW-w64 had '_InterlockedExchange' (= __cdecl decoration). [3] Regards, /Pete [1] http://msdn.microsoft.com/en-us/library/ms683614%28VS.85%29.aspx [2] http://libusb.6.n5.nabble.com/Win-libusb-1-0-snapshots-no-longer-work-with-cross-compiling-of-libftdi-1-0-td2262878.html#a2262878 [3] http://libusb.6.n5.nabble.com/Win-libusb-1-0-snapshots-no-longer-work-with-cross-compiling-of-libftdi-1-0-tp2262878p2473397.html -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] discrepancy between MinGW32 and MinGW-w64 winbase.h (Interlocked API)
2010/8/17 Ozkan Sezer seze...@gmail.com: On Tue, Aug 17, 2010 at 2:44 PM, Kai Tietz ktiet...@googlemail.com wrote: 2010/8/17 Pete Batard pbat...@gmail.com: On 2010.08.17 12:29, Ozkan Sezer wrote: Thank you Pete for noticing that. We are aware of this and we solved things here a bit different, but AFAIR, they aren't specifically marked as WINAPI in ms headers (well, maybe their mistake?..) Well, the thing is that the MSDN documentation has __cdecl [1], but looking at WinBase.h from a Visual Studio 2008 installation, there's a definite WINAPI qualifier on 32 bit. So there's some conflicting data there... I would think that if both MinGW32 and VS's WinBase.h use WINAPI on 32 bit, MinGW-w64 probably wants to follow suit maybe we could add here the stdcall decoration, too. Our Interlocked API is treated in our libmingwex and has here (as intrinsic) the __cdecl decoration. Therefore it shouldn't produce for you in general issues. Do you have here found issues while building? I'm afraid we have. When compiling libusb 1.0 in a multilib MinGW-w64 environment, we found that the resulting 32 bit library was unusable in MinGW32 [2]. Looking at it more closely, we found that the pure MinGW32 binary had '_interlockedexcha...@8' (= __stdcall decoration) whereas the -m32 MinGW-w64 had '_InterlockedExchange' (= __cdecl decoration). [3] Regards, /Pete [1] http://msdn.microsoft.com/en-us/library/ms683614%28VS.85%29.aspx [2] http://libusb.6.n5.nabble.com/Win-libusb-1-0-snapshots-no-longer-work-with-cross-compiling-of-libftdi-1-0-td2262878.html#a2262878 [3] http://libusb.6.n5.nabble.com/Win-libusb-1-0-snapshots-no-longer-work-with-cross-compiling-of-libftdi-1-0-tp2262878p2473397.html Ok, thanks for explaination. We will adjust this soon. Ozkan do you want to take care here? I can. However I'd like to have a strict definition of what to do here: in winbase.h, I can change the Interlocked* api to __stdcall, but as I said that may cause problems with software compiled using older versions of mingw-w64. Are we OK with this? I think we are here. As we provide in general all of those intrinsic in our libmingex, the users shouldn't notice it. Those symbols aren't treated here in general as imported. Kai PS: For 64-bit this is a non-issue as x64 always uses a fastcall convention and the stdcall/thiscall/cdecl are all in fact fastcall, too. s / __fastcall / __cdecl / ??? No, fastcall is the default calling-convention. Register are used for argument passing for the first 4 arguments. But don't come to the idea that they would be freely-exchangable, as compiler makes here still differences about used calling-convention and will warning if you are mixing things up here. Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] discrepancy between MinGW32 and MinGW-w64 winbase.h (Interlocked API)
On Tue, Aug 17, 2010 at 2:52 PM, Kai Tietz ktiet...@googlemail.com wrote: 2010/8/17 Ozkan Sezer seze...@gmail.com: On Tue, Aug 17, 2010 at 2:44 PM, Kai Tietz ktiet...@googlemail.com wrote: 2010/8/17 Pete Batard pbat...@gmail.com: On 2010.08.17 12:29, Ozkan Sezer wrote: Thank you Pete for noticing that. We are aware of this and we solved things here a bit different, but AFAIR, they aren't specifically marked as WINAPI in ms headers (well, maybe their mistake?..) Well, the thing is that the MSDN documentation has __cdecl [1], but looking at WinBase.h from a Visual Studio 2008 installation, there's a definite WINAPI qualifier on 32 bit. So there's some conflicting data there... I would think that if both MinGW32 and VS's WinBase.h use WINAPI on 32 bit, MinGW-w64 probably wants to follow suit maybe we could add here the stdcall decoration, too. Our Interlocked API is treated in our libmingwex and has here (as intrinsic) the __cdecl decoration. Therefore it shouldn't produce for you in general issues. Do you have here found issues while building? I'm afraid we have. When compiling libusb 1.0 in a multilib MinGW-w64 environment, we found that the resulting 32 bit library was unusable in MinGW32 [2]. Looking at it more closely, we found that the pure MinGW32 binary had '_interlockedexcha...@8' (= __stdcall decoration) whereas the -m32 MinGW-w64 had '_InterlockedExchange' (= __cdecl decoration). [3] Regards, /Pete [1] http://msdn.microsoft.com/en-us/library/ms683614%28VS.85%29.aspx [2] http://libusb.6.n5.nabble.com/Win-libusb-1-0-snapshots-no-longer-work-with-cross-compiling-of-libftdi-1-0-td2262878.html#a2262878 [3] http://libusb.6.n5.nabble.com/Win-libusb-1-0-snapshots-no-longer-work-with-cross-compiling-of-libftdi-1-0-tp2262878p2473397.html Ok, thanks for explaination. We will adjust this soon. Ozkan do you want to take care here? I can. However I'd like to have a strict definition of what to do here: in winbase.h, I can change the Interlocked* api to __stdcall, but as I said that may cause problems with software compiled using older versions of mingw-w64. Are we OK with this? I think we are here. As we provide in general all of those intrinsic in our libmingex, the users shouldn't notice it. Those symbols aren't treated here in general as imported. Hmm, thinking a little more, this need not be as much of an issue: we have __cdecl versions in libmingwex, if we change into __stdcall then old software can still succeed linking to libmingwex but new ones will link to kernel32, so all we have to do is not change the local implementations and keep them as __cdecl. Am I correct? Kai PS: For 64-bit this is a non-issue as x64 always uses a fastcall convention and the stdcall/thiscall/cdecl are all in fact fastcall, too. s / __fastcall / __cdecl / ??? No, fastcall is the default calling-convention. Register are used for argument passing for the first 4 arguments. But don't come to the idea that they would be freely-exchangable, as compiler makes here still differences about used calling-convention and will warning if you are mixing things up here. OK Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination -- Ozkan -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] discrepancy between MinGW32 and MinGW-w64 winbase.h (Interlocked API)
2010/8/17 Kai Tietz ktiet...@googlemail.com: 2010/8/17 Ozkan Sezer seze...@gmail.com: On Tue, Aug 17, 2010 at 2:44 PM, Kai Tietz ktiet...@googlemail.com wrote: 2010/8/17 Pete Batard pbat...@gmail.com: On 2010.08.17 12:29, Ozkan Sezer wrote: Thank you Pete for noticing that. We are aware of this and we solved things here a bit different, but AFAIR, they aren't specifically marked as WINAPI in ms headers (well, maybe their mistake?..) Well, the thing is that the MSDN documentation has __cdecl [1], but looking at WinBase.h from a Visual Studio 2008 installation, there's a definite WINAPI qualifier on 32 bit. So there's some conflicting data there... I would think that if both MinGW32 and VS's WinBase.h use WINAPI on 32 bit, MinGW-w64 probably wants to follow suit maybe we could add here the stdcall decoration, too. Our Interlocked API is treated in our libmingwex and has here (as intrinsic) the __cdecl decoration. Therefore it shouldn't produce for you in general issues. Do you have here found issues while building? I'm afraid we have. When compiling libusb 1.0 in a multilib MinGW-w64 environment, we found that the resulting 32 bit library was unusable in MinGW32 [2]. Looking at it more closely, we found that the pure MinGW32 binary had '_interlockedexcha...@8' (= __stdcall decoration) whereas the -m32 MinGW-w64 had '_InterlockedExchange' (= __cdecl decoration). [3] Regards, /Pete [1] http://msdn.microsoft.com/en-us/library/ms683614%28VS.85%29.aspx [2] http://libusb.6.n5.nabble.com/Win-libusb-1-0-snapshots-no-longer-work-with-cross-compiling-of-libftdi-1-0-td2262878.html#a2262878 [3] http://libusb.6.n5.nabble.com/Win-libusb-1-0-snapshots-no-longer-work-with-cross-compiling-of-libftdi-1-0-tp2262878p2473397.html Ok, thanks for explaination. We will adjust this soon. Ozkan do you want to take care here? I can. However I'd like to have a strict definition of what to do here: in winbase.h, I can change the Interlocked* api to __stdcall, but as I said that may cause problems with software compiled using older versions of mingw-w64. Are we OK with this? I think we are here. As we provide in general all of those intrinsic in our libmingex, the users shouldn't notice it. Those symbols aren't treated here in general as imported. Kai PS: For 64-bit this is a non-issue as x64 always uses a fastcall convention and the stdcall/thiscall/cdecl are all in fact fastcall, too. s / __fastcall / __cdecl / ??? No, fastcall is the default calling-convention. Register are used for argument passing for the first 4 arguments. But don't come to the idea that they would be freely-exchangable, as compiler makes here still differences about used calling-convention and will warning if you are mixing things up here. Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination Pete, could you provide us a list of the Interlock* API, which has stdcall calling convention by our findings? Please just list names of those functions and don't copy from VC's header-set. So we can adjust things for win32 more easily without violating EULA. Thanks, Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] discrepancy between MinGW32 and MinGW-w64 winbase.h (Interlocked API)
2010/8/17 Ozkan Sezer seze...@gmail.com: On Tue, Aug 17, 2010 at 2:52 PM, Kai Tietz ktiet...@googlemail.com wrote: 2010/8/17 Ozkan Sezer seze...@gmail.com: On Tue, Aug 17, 2010 at 2:44 PM, Kai Tietz ktiet...@googlemail.com wrote: 2010/8/17 Pete Batard pbat...@gmail.com: On 2010.08.17 12:29, Ozkan Sezer wrote: Thank you Pete for noticing that. We are aware of this and we solved things here a bit different, but AFAIR, they aren't specifically marked as WINAPI in ms headers (well, maybe their mistake?..) Well, the thing is that the MSDN documentation has __cdecl [1], but looking at WinBase.h from a Visual Studio 2008 installation, there's a definite WINAPI qualifier on 32 bit. So there's some conflicting data there... I would think that if both MinGW32 and VS's WinBase.h use WINAPI on 32 bit, MinGW-w64 probably wants to follow suit maybe we could add here the stdcall decoration, too. Our Interlocked API is treated in our libmingwex and has here (as intrinsic) the __cdecl decoration. Therefore it shouldn't produce for you in general issues. Do you have here found issues while building? I'm afraid we have. When compiling libusb 1.0 in a multilib MinGW-w64 environment, we found that the resulting 32 bit library was unusable in MinGW32 [2]. Looking at it more closely, we found that the pure MinGW32 binary had '_interlockedexcha...@8' (= __stdcall decoration) whereas the -m32 MinGW-w64 had '_InterlockedExchange' (= __cdecl decoration). [3] Regards, /Pete [1] http://msdn.microsoft.com/en-us/library/ms683614%28VS.85%29.aspx [2] http://libusb.6.n5.nabble.com/Win-libusb-1-0-snapshots-no-longer-work-with-cross-compiling-of-libftdi-1-0-td2262878.html#a2262878 [3] http://libusb.6.n5.nabble.com/Win-libusb-1-0-snapshots-no-longer-work-with-cross-compiling-of-libftdi-1-0-tp2262878p2473397.html Ok, thanks for explaination. We will adjust this soon. Ozkan do you want to take care here? I can. However I'd like to have a strict definition of what to do here: in winbase.h, I can change the Interlocked* api to __stdcall, but as I said that may cause problems with software compiled using older versions of mingw-w64. Are we OK with this? I think we are here. As we provide in general all of those intrinsic in our libmingex, the users shouldn't notice it. Those symbols aren't treated here in general as imported. Hmm, thinking a little more, this need not be as much of an issue: we have __cdecl versions in libmingwex, if we change into __stdcall then old software can still succeed linking to libmingwex but new ones will link to kernel32, so all we have to do is not change the local implementations and keep them as __cdecl. Am I correct? No, we need to change local implementation, too. Otherwise call stack gets broken. If we do this change, we have to change them all or none. Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] discrepancy between MinGW32 and MinGW-w64 winbase.h (Interlocked API)
On 2010.08.17 12:55, Kai Tietz wrote: Pete, could you provide us a list of the Interlock* API, which has stdcall calling convention by our findings? Please just list names of those functions and don't copy from VC's header-set. So we can adjust things for win32 more easily without violating EULA. Thanks for the speedy replies. As far as we are concerned, we only had InterlockedExchange and InterlockedIncrement being a problem, as these are the only 2 call from Interlocked API we use. The following is copied from MinGW32's winbase.h [1] which should work with your EULA. It looks like you might need to add some #ifdefs as well: #if !(__USE_NTOSKRNL__) /* CAREFUL: These are exported from ntoskrnl.exe and declared in winddk.h as __fastcall functions, but are exported from kernel32.dll as __stdcall */ #if (_WIN32_WINNT = 0x0501) WINBASEAPI VOID WINAPI InitializeSListHead(PSLIST_HEADER); #endif #ifndef __INTERLOCKED_DECLARED #define __INTERLOCKED_DECLARED LONG WINAPI InterlockedCompareExchange(LONG volatile *,LONG,LONG); /* PVOID WINAPI InterlockedCompareExchangePointer(PVOID*,PVOID,PVOID); */ #define InterlockedCompareExchangePointer(d,e,c) \ (PVOID)InterlockedCompareExchange((LONG volatile *)(d),(LONG)(e),(LONG)(c)) LONG WINAPI InterlockedDecrement(LONG volatile *); LONG WINAPI InterlockedExchange(LONG volatile *,LONG); /* PVOID WINAPI InterlockedExchangePointer(PVOID*,PVOID); */ #define InterlockedExchangePointer(t,v) \ (PVOID)InterlockedExchange((LONG volatile *)(t),(LONG)(v)) LONG WINAPI InterlockedExchangeAdd(LONG volatile *,LONG); #if (_WIN32_WINNT = 0x0501) PSLIST_ENTRY WINAPI InterlockedFlushSList(PSLIST_HEADER); #endif LONG WINAPI InterlockedIncrement(LONG volatile *); #if (_WIN32_WINNT = 0x0501) PSLIST_ENTRY WINAPI InterlockedPopEntrySList(PSLIST_HEADER); PSLIST_ENTRY WINAPI InterlockedPushEntrySList(PSLIST_HEADER,PSLIST_ENTRY); #endif #endif /* __INTERLOCKED_DECLARED */ #endif /* __USE_NTOSKRNL__ */ Regards, /Pete [1] http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/winbase.h?rev=1.98content-type=text/x-cvsweb-markupcvsroot=src -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] discrepancy between MinGW32 and MinGW-w64 winbase.h (Interlocked API)
2010/8/17 Pete Batard pbat...@gmail.com: On 2010.08.17 12:55, Kai Tietz wrote: Pete, could you provide us a list of the Interlock* API, which has stdcall calling convention by our findings? Please just list names of those functions and don't copy from VC's header-set. So we can adjust things for win32 more easily without violating EULA. Thanks for the speedy replies. As far as we are concerned, we only had InterlockedExchange and InterlockedIncrement being a problem, as these are the only 2 call from Interlocked API we use. The following is copied from MinGW32's winbase.h [1] which should work with your EULA. It looks like you might need to add some #ifdefs as well: #if !(__USE_NTOSKRNL__) /* CAREFUL: These are exported from ntoskrnl.exe and declared in winddk.h as __fastcall functions, but are exported from kernel32.dll as __stdcall */ #if (_WIN32_WINNT = 0x0501) WINBASEAPI VOID WINAPI InitializeSListHead(PSLIST_HEADER); #endif #ifndef __INTERLOCKED_DECLARED #define __INTERLOCKED_DECLARED LONG WINAPI InterlockedCompareExchange(LONG volatile *,LONG,LONG); /* PVOID WINAPI InterlockedCompareExchangePointer(PVOID*,PVOID,PVOID); */ #define InterlockedCompareExchangePointer(d,e,c) \ (PVOID)InterlockedCompareExchange((LONG volatile *)(d),(LONG)(e),(LONG)(c)) LONG WINAPI InterlockedDecrement(LONG volatile *); LONG WINAPI InterlockedExchange(LONG volatile *,LONG); /* PVOID WINAPI InterlockedExchangePointer(PVOID*,PVOID); */ #define InterlockedExchangePointer(t,v) \ (PVOID)InterlockedExchange((LONG volatile *)(t),(LONG)(v)) LONG WINAPI InterlockedExchangeAdd(LONG volatile *,LONG); #if (_WIN32_WINNT = 0x0501) PSLIST_ENTRY WINAPI InterlockedFlushSList(PSLIST_HEADER); #endif LONG WINAPI InterlockedIncrement(LONG volatile *); #if (_WIN32_WINNT = 0x0501) PSLIST_ENTRY WINAPI InterlockedPopEntrySList(PSLIST_HEADER); PSLIST_ENTRY WINAPI InterlockedPushEntrySList(PSLIST_HEADER,PSLIST_ENTRY); #endif #endif /* __INTERLOCKED_DECLARED */ #endif /* __USE_NTOSKRNL__ */ Regards, /Pete [1] http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/winbase.h?rev=1.98content-type=text/x-cvsweb-markupcvsroot=src Ozkan, do you remember the issue we had about _Interlocked and the Interlocked... API? As more as I think about it as more it seems to me that the leading underscore variant has cdecl, and the none-underscore variant has stdcall convention. Fridrich: Could you try to enlight us here? Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] discrepancy between MinGW32 and MinGW-w64 winbase.h (Interlocked API)
On Tue, Aug 17, 2010 at 3:50 PM, Kai Tietz ktiet...@googlemail.com wrote: 2010/8/17 Pete Batard pbat...@gmail.com: On 2010.08.17 12:55, Kai Tietz wrote: Pete, could you provide us a list of the Interlock* API, which has stdcall calling convention by our findings? Please just list names of those functions and don't copy from VC's header-set. So we can adjust things for win32 more easily without violating EULA. Thanks for the speedy replies. As far as we are concerned, we only had InterlockedExchange and InterlockedIncrement being a problem, as these are the only 2 call from Interlocked API we use. The following is copied from MinGW32's winbase.h [1] which should work with your EULA. It looks like you might need to add some #ifdefs as well: #if !(__USE_NTOSKRNL__) /* CAREFUL: These are exported from ntoskrnl.exe and declared in winddk.h as __fastcall functions, but are exported from kernel32.dll as __stdcall */ #if (_WIN32_WINNT = 0x0501) WINBASEAPI VOID WINAPI InitializeSListHead(PSLIST_HEADER); #endif #ifndef __INTERLOCKED_DECLARED #define __INTERLOCKED_DECLARED LONG WINAPI InterlockedCompareExchange(LONG volatile *,LONG,LONG); /* PVOID WINAPI InterlockedCompareExchangePointer(PVOID*,PVOID,PVOID); */ #define InterlockedCompareExchangePointer(d,e,c) \ (PVOID)InterlockedCompareExchange((LONG volatile *)(d),(LONG)(e),(LONG)(c)) LONG WINAPI InterlockedDecrement(LONG volatile *); LONG WINAPI InterlockedExchange(LONG volatile *,LONG); /* PVOID WINAPI InterlockedExchangePointer(PVOID*,PVOID); */ #define InterlockedExchangePointer(t,v) \ (PVOID)InterlockedExchange((LONG volatile *)(t),(LONG)(v)) LONG WINAPI InterlockedExchangeAdd(LONG volatile *,LONG); #if (_WIN32_WINNT = 0x0501) PSLIST_ENTRY WINAPI InterlockedFlushSList(PSLIST_HEADER); #endif LONG WINAPI InterlockedIncrement(LONG volatile *); #if (_WIN32_WINNT = 0x0501) PSLIST_ENTRY WINAPI InterlockedPopEntrySList(PSLIST_HEADER); PSLIST_ENTRY WINAPI InterlockedPushEntrySList(PSLIST_HEADER,PSLIST_ENTRY); #endif #endif /* __INTERLOCKED_DECLARED */ #endif /* __USE_NTOSKRNL__ */ Regards, /Pete [1] http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/winbase.h?rev=1.98content-type=text/x-cvsweb-markupcvsroot=src Ozkan, do you remember the issue we had about _Interlocked and the Interlocked... API? As more as I think about it as more it seems to me that the leading underscore variant has cdecl, and the none-underscore variant has stdcall convention. Can't remember. Let me try and dig old stuff and see if I can find anything Fridrich: Could you try to enlight us here? Kai -- Ozkan -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] discrepancy between MinGW32 and MinGW-w64 winbase.h (Interlocked API)
2010/8/17 Ozkan Sezer seze...@gmail.com: On Tue, Aug 17, 2010 at 3:50 PM, Kai Tietz ktiet...@googlemail.com wrote: 2010/8/17 Pete Batard pbat...@gmail.com: On 2010.08.17 12:55, Kai Tietz wrote: Pete, could you provide us a list of the Interlock* API, which has stdcall calling convention by our findings? Please just list names of those functions and don't copy from VC's header-set. So we can adjust things for win32 more easily without violating EULA. Thanks for the speedy replies. As far as we are concerned, we only had InterlockedExchange and InterlockedIncrement being a problem, as these are the only 2 call from Interlocked API we use. The following is copied from MinGW32's winbase.h [1] which should work with your EULA. It looks like you might need to add some #ifdefs as well: #if !(__USE_NTOSKRNL__) /* CAREFUL: These are exported from ntoskrnl.exe and declared in winddk.h as __fastcall functions, but are exported from kernel32.dll as __stdcall */ #if (_WIN32_WINNT = 0x0501) WINBASEAPI VOID WINAPI InitializeSListHead(PSLIST_HEADER); #endif #ifndef __INTERLOCKED_DECLARED #define __INTERLOCKED_DECLARED LONG WINAPI InterlockedCompareExchange(LONG volatile *,LONG,LONG); /* PVOID WINAPI InterlockedCompareExchangePointer(PVOID*,PVOID,PVOID); */ #define InterlockedCompareExchangePointer(d,e,c) \ (PVOID)InterlockedCompareExchange((LONG volatile *)(d),(LONG)(e),(LONG)(c)) LONG WINAPI InterlockedDecrement(LONG volatile *); LONG WINAPI InterlockedExchange(LONG volatile *,LONG); /* PVOID WINAPI InterlockedExchangePointer(PVOID*,PVOID); */ #define InterlockedExchangePointer(t,v) \ (PVOID)InterlockedExchange((LONG volatile *)(t),(LONG)(v)) LONG WINAPI InterlockedExchangeAdd(LONG volatile *,LONG); #if (_WIN32_WINNT = 0x0501) PSLIST_ENTRY WINAPI InterlockedFlushSList(PSLIST_HEADER); #endif LONG WINAPI InterlockedIncrement(LONG volatile *); #if (_WIN32_WINNT = 0x0501) PSLIST_ENTRY WINAPI InterlockedPopEntrySList(PSLIST_HEADER); PSLIST_ENTRY WINAPI InterlockedPushEntrySList(PSLIST_HEADER,PSLIST_ENTRY); #endif #endif /* __INTERLOCKED_DECLARED */ #endif /* __USE_NTOSKRNL__ */ Regards, /Pete [1] http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/winbase.h?rev=1.98content-type=text/x-cvsweb-markupcvsroot=src Ozkan, do you remember the issue we had about _Interlocked and the Interlocked... API? As more as I think about it as more it seems to me that the leading underscore variant has cdecl, and the none-underscore variant has stdcall convention. Can't remember. Let me try and dig old stuff and see if I can find anything Fridrich: Could you try to enlight us here? Kai Yeah, this could make sense that Interlocked... is for x86 stdcall, and _Interlocked... is cdecl. As you can see in winbase.h that for ia64 and x64 the Interlocked... API is treated like the _Interlocked... API (as here no calling convention differences are used). But for x86 this doesn't happen. So I am pretty sure that this is the jumping point we misinterpreted here. Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] discrepancy between MinGW32 and MinGW-w64 winbase.h (Interlocked API)
2010/8/17 Ozkan Sezer seze...@gmail.com: On Tue, Aug 17, 2010 at 4:08 PM, Kai Tietz ktiet...@googlemail.com wrote: 2010/8/17 Ozkan Sezer seze...@gmail.com: On Tue, Aug 17, 2010 at 3:50 PM, Kai Tietz ktiet...@googlemail.com wrote: 2010/8/17 Pete Batard pbat...@gmail.com: On 2010.08.17 12:55, Kai Tietz wrote: Pete, could you provide us a list of the Interlock* API, which has stdcall calling convention by our findings? Please just list names of those functions and don't copy from VC's header-set. So we can adjust things for win32 more easily without violating EULA. Thanks for the speedy replies. As far as we are concerned, we only had InterlockedExchange and InterlockedIncrement being a problem, as these are the only 2 call from Interlocked API we use. The following is copied from MinGW32's winbase.h [1] which should work with your EULA. It looks like you might need to add some #ifdefs as well: #if !(__USE_NTOSKRNL__) /* CAREFUL: These are exported from ntoskrnl.exe and declared in winddk.h as __fastcall functions, but are exported from kernel32.dll as __stdcall */ #if (_WIN32_WINNT = 0x0501) WINBASEAPI VOID WINAPI InitializeSListHead(PSLIST_HEADER); #endif #ifndef __INTERLOCKED_DECLARED #define __INTERLOCKED_DECLARED LONG WINAPI InterlockedCompareExchange(LONG volatile *,LONG,LONG); /* PVOID WINAPI InterlockedCompareExchangePointer(PVOID*,PVOID,PVOID); */ #define InterlockedCompareExchangePointer(d,e,c) \ (PVOID)InterlockedCompareExchange((LONG volatile *)(d),(LONG)(e),(LONG)(c)) LONG WINAPI InterlockedDecrement(LONG volatile *); LONG WINAPI InterlockedExchange(LONG volatile *,LONG); /* PVOID WINAPI InterlockedExchangePointer(PVOID*,PVOID); */ #define InterlockedExchangePointer(t,v) \ (PVOID)InterlockedExchange((LONG volatile *)(t),(LONG)(v)) LONG WINAPI InterlockedExchangeAdd(LONG volatile *,LONG); #if (_WIN32_WINNT = 0x0501) PSLIST_ENTRY WINAPI InterlockedFlushSList(PSLIST_HEADER); #endif LONG WINAPI InterlockedIncrement(LONG volatile *); #if (_WIN32_WINNT = 0x0501) PSLIST_ENTRY WINAPI InterlockedPopEntrySList(PSLIST_HEADER); PSLIST_ENTRY WINAPI InterlockedPushEntrySList(PSLIST_HEADER,PSLIST_ENTRY); #endif #endif /* __INTERLOCKED_DECLARED */ #endif /* __USE_NTOSKRNL__ */ Regards, /Pete [1] http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/winbase.h?rev=1.98content-type=text/x-cvsweb-markupcvsroot=src Ozkan, do you remember the issue we had about _Interlocked and the Interlocked... API? As more as I think about it as more it seems to me that the leading underscore variant has cdecl, and the none-underscore variant has stdcall convention. Can't remember. Let me try and dig old stuff and see if I can find anything Fridrich: Could you try to enlight us here? Kai Yeah, this could make sense that Interlocked... is for x86 stdcall, and _Interlocked... is cdecl. As you can see in winbase.h that for ia64 and x64 the Interlocked... API is treated like the _Interlocked... API (as here no calling convention differences are used). But for x86 this doesn't happen. So I am pretty sure that this is the jumping point we misinterpreted here. Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination These are the ones that are exported from kernel32.dll acc. to trunk's kernel32.def: interlockedcompareexchang...@20 interlockedcompareexcha...@12 interlockeddecrem...@4 interlockedexcha...@8 interlockedexchange...@8 interlockedflushsl...@4 interlockedincrem...@4 These are the ones that are exported from ntoskrnl.exe acc.to trunk's ntoskrnl.def: @interlockedcompareexcha...@12 @interlockeddecrem...@4 @interlockedexcha...@8 @interlockedexchange...@8 @interlockedincrem...@4 So there are no _Interlocked* here, which means that all those _Interlocked* are ms intrinsics *and* they must always be inlines, ie. not just _CRT_INLINE but FORCEINLINE for us. When they are inlines, I guess __cdecl or __stdcall doesn't matter. that must be where we started to err. This is uglier that it looks... See intrin.h and the definitions of those intrinsic. They have here cdecl convention. So _Interlocked... is cdecl and Interlocked... is for x86 stdcall. This change affects winnt.h and winbase.h. And of course we need to do here special casing for stdcall variant for 32-bit (the aliasing) in our crt libmingwex. Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
