<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Thanks, but not quite. The number of parameters times four needs to be appended to the name, in decimal.<BR>
But I'm just getting 0.<BR>
That is, gcc is handling the underlying detail, but you aren't giving it enough infomrmation.<BR>
I'll see if I can bang out those temporary wrappers automatically.. (a Quake programming challenge, that I've already invented the hard part of I think -- Quake can't do math..)<BR>
<BR>
- Jay<BR><BR>
<HR id=stopSpelling>
<BR>
> CC: m3devel@elegosoft.com<BR>> From: hosking@cs.purdue.edu<BR>> Subject: Re: [M3devel] could someone add __stdcall name mangling to m3cc please?<BR>> Date: Fri, 11 Jan 2008 13:16:44 -0500<BR>> To: jayk123@hotmail.com<BR>> <BR>> I just added support for this. Let me know if it seems to work (or <BR>> not! :-) ).<BR>> <BR>> <BR>> On Jan 10, 2008, at 7:40 AM, Jay wrote:<BR>> <BR>> > Could someone out there (Tony?) familiar with the gcc backend<BR>> > have it not ignore call_conv and if call_conv is 1, append<BR>> > an at symbol and the number of bytes of parameters to the function <BR>> > name?<BR>> > (Even for zero, e.g. Sleep@0, GetFileAttributes@4).<BR>> > This would be I guess at least for "imported" functions.<BR>> ><BR>> > Not clear about calling function pointers, probably needs <BR>> > modification.<BR>> > call_conv 0 is "__cdecl" is push right to left, caller cleans up<BR>> > call_conv 1 is "__stdcall" is push right to left, callee cleans up<BR>> > There are various synonyms.<BR>> > With no command line switches, __cdecl is the compiler default.<BR>> > __stdcall is deemed more efficient, and is very widely used.<BR>> ><BR>> > Not clear about functions implemented in Modula-3.<BR>> > Probably won't occur? Maybe for callbacks? WindowProcs, thread <BR>> > entry point?<BR>> ><BR>> > This could/should be for NT386GNU only.<BR>> > The hypothetical other NT targets only have one calling convention <BR>> > each.<BR>> ><BR>> > I COULD do something sleazy here and generate little adapter <BR>> > functions, over in m3-win/import-libs esp.<BR>> ><BR>> > I'm still checking out pm3 to see what it does here.<BR>> > (as in cvs checkout, not "looking at")<BR>> ><BR>> > This'll clear up:<BR>> ><BR>> > RTOS.m3:27: undefined reference to `_FatalExit'<BR>> > RTOS.mo: In function `RTOS__GetMemory':<BR>> > RTOS.m3:75: undefined reference to `_VirtualAlloc'<BR>> > RTOS.m3:85: undefined reference to `_VirtualAlloc'<BR>> > RTOS.mo: In function `RTOS__InitMemory':<BR>> > RTOS.m3:96: undefined reference to `_VirtualAlloc'<BR>> > RTOS.m3:100: undefined reference to `_GetSystemInfo'<BR>> > RTOS.mo: In function `RTOS__Write':<BR>> > RTOS.m3:118: undefined reference to `_AllocConsole'<BR>> > RTOS.m3:119: undefined reference to `_GetStdHandle'<BR>> > RTOS.m3:122: undefined reference to `_WriteFile'<BR>> > RTPerfTool.mo: In function `RTPerfTool__Start':<BR>> > RTPerfTool.m3:19: undefined reference to `_ReadFile'<BR>> > RTPerfTool.m3:22: undefined reference to `_CloseHandle'<BR>> > RTPerfTool.mo: In function `RTPerfTool__Close':<BR>> > RTPerfTool.m3:28: undefined reference to `_CloseHandle'<BR>> > RTPerfTool.mo: In function `RTPerfTool__Send':<BR>> > RTPerfTool.m3:34: undefined reference to `_WriteFile'<BR>> > RTPerfTool.mo: In function `RTPerfTool__PrepHandle':<BR>> > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'<BR>> > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'<BR>> > etc.<BR>> ><BR>> > I did think I was past these. I thought I built m3core and libm3 <BR>> > including linking (having even modified cm3.cfg)<BR>> > COULD be I'm using the wrong .libs, but:<BR>> ><BR>> > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile<BR>> > 00000000 I __imp__CreateFileW@28<BR>> > 00000000 T _CreateFileW@28<BR>> > 00000000 I __imp__CreateFileMappingW@24<BR>> > 00000000 T _CreateFileMappingW@24<BR>> > 00000000 I __imp__CreateFileMappingA@24<BR>> > 00000000 T _CreateFileMappingA@24<BR>> > 00000000 I __imp__CreateFileA@28<BR>> > 00000000 T _CreateFileA@28<BR>> ><BR>> > C:\cygwin\lib\w32api>cd \MinGW\lib<BR>> ><BR>> > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile<BR>> > 00000000 I __imp__CreateFileW@28<BR>> > 00000000 T _CreateFileW@28<BR>> > 00000000 I __imp__CreateFileMappingW@24<BR>> > 00000000 T _CreateFileMappingW@24<BR>> > 00000000 I __imp__CreateFileMappingA@24<BR>> > 00000000 T _CreateFileMappingA@24<BR>> > 00000000 I __imp__CreateFileA@28<BR>> > 00000000 T _CreateFileA@28<BR>> ><BR>> > I think at least THREE calling conventions should be supported -- <BR>> > __cdecl, __stdcall, __fastcall --<BR>> > but oh well. We can live without __fastcall.<BR>> > Watcom has another calling convention, "watcall", and they let you <BR>> > describe calling conventions with #pragmas, neat.<BR>> ><BR>> > Thanks,<BR>> > - Jay<BR>> ><BR>> > Share life as it happens with the new Windows Live. Start sharing!<BR>> <BR><BR><br /><hr />Make distant family not so distant with Windows Vista® + Windows Live™. <a href='http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008' target='_new'>Start now!</a></body>
</html>