On Tue, Aug 17, 2010 at 4:08 PM, Kai Tietz <[email protected]> wrote: > 2010/8/17 Ozkan Sezer <[email protected]>: >> On Tue, Aug 17, 2010 at 3:50 PM, Kai Tietz <[email protected]> wrote: >>> 2010/8/17 Pete Batard <[email protected]>: >>>> 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.98&content-type=text/x-cvsweb-markup&cvsroot=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... ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
