[M3devel] could someone add __stdcall name mangling to m3cc please?

[Jay]

Tony, Sorry, I didn't mean to check those in. Those were wild guesses that I hadn't tested yet.I put it back. Thanks for catching that.
 
 - Jay



> CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] could someone add __stdcall name mangling to m3cc please?> Date: Sat, 12 Jan 2008 10:41:26 -0500> To: jayk123 at hotmail.com> > I'm not sure what you were trying to do with parse.c by adding a > parameter (nargs*4) to the stdcall attribute, but that probably > doesn't do anything interesting. The problem appears to be because > on external function decls the parameter decls are currently being > ignored by cm3cg. If I fix parse.c to add the params for those then > it should work properly with the stdcall attribute.> > On Jan 12, 2008, at 8:27 AM, Jay wrote:> > > Thanks, but not quite. The number of parameters times four needs to > > be appended to the name, in decimal.> > But I'm just getting 0.> > That is, gcc is handling the underlying detail, but you aren't > > giving it enough infomrmation.> > 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..)> >> > - Jay> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > to m3cc please?> > > Date: Fri, 11 Jan 2008 13:16:44 -0500> > > To: jayk123 at hotmail.com> > >> > > I just added support for this. Let me know if it seems to work (or> > > not! :-) ).> > >> > >> > > On Jan 10, 2008, at 7:40 AM, Jay wrote:> > >> > > > Could someone out there (Tony?) familiar with the gcc backend> > > > have it not ignore call_conv and if call_conv is 1, append> > > > an at symbol and the number of bytes of parameters to the function> > > > name?> > > > (Even for zero, e.g. Sleep at 0, GetFileAttributes at 4).> > > > This would be I guess at least for "imported" functions.> > > >> > > > Not clear about calling function pointers, probably needs> > > > modification.> > > > call_conv 0 is "__cdecl" is push right to left, caller cleans up> > > > call_conv 1 is "__stdcall" is push right to left, callee cleans up> > > > There are various synonyms.> > > > With no command line switches, __cdecl is the compiler default.> > > > __stdcall is deemed more efficient, and is very widely used.> > > >> > > > Not clear about functions implemented in Modula-3.> > > > Probably won't occur? Maybe for callbacks? WindowProcs, thread> > > > entry point?> > > >> > > > This could/should be for NT386GNU only.> > > > The hypothetical other NT targets only have one calling convention> > > > each.> > > >> > > > I COULD do something sleazy here and generate little adapter> > > > functions, over in m3-win/import-libs esp.> > > >> > > > I'm still checking out pm3 to see what it does here.> > > > (as in cvs checkout, not "looking at")> > > >> > > > This'll clear up:> > > >> > > > RTOS.m3:27: undefined reference to `_FatalExit'> > > > RTOS.mo: In function `RTOS__GetMemory':> > > > RTOS.m3:75: undefined reference to `_VirtualAlloc'> > > > RTOS.m3:85: undefined reference to `_VirtualAlloc'> > > > RTOS.mo: In function `RTOS__InitMemory':> > > > RTOS.m3:96: undefined reference to `_VirtualAlloc'> > > > RTOS.m3:100: undefined reference to `_GetSystemInfo'> > > > RTOS.mo: In function `RTOS__Write':> > > > RTOS.m3:118: undefined reference to `_AllocConsole'> > > > RTOS.m3:119: undefined reference to `_GetStdHandle'> > > > RTOS.m3:122: undefined reference to `_WriteFile'> > > > RTPerfTool.mo: In function `RTPerfTool__Start':> > > > RTPerfTool.m3:19: undefined reference to `_ReadFile'> > > > RTPerfTool.m3:22: undefined reference to `_CloseHandle'> > > > RTPerfTool.mo: In function `RTPerfTool__Close':> > > > RTPerfTool.m3:28: undefined reference to `_CloseHandle'> > > > RTPerfTool.mo: In function `RTPerfTool__Send':> > > > RTPerfTool.m3:34: undefined reference to `_WriteFile'> > > > RTPerfTool.mo: In function `RTPerfTool__PrepHandle':> > > > RTPerfTool.m3:58: undefined reference to `_GetCurrentProcess'> > > > RTPerfTool.m3:59: undefined reference to `_DuplicateHandle'> > > > etc.> > > >> > > > I did think I was past these. I thought I built m3core and libm3> > > > including linking (having even modified cm3.cfg)> > > > COULD be I'm using the wrong .libs, but:> > > >> > > > C:\cygwin\lib\w32api>nm libkernel32.a | findstr CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I __imp__CreateFileMappingA at 24> > > > 00000000 T _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > 00000000 T _CreateFileA at 28> > > >> > > > C:\cygwin\lib\w32api>cd \MinGW\lib> > > >> > > > C:\MinGW\lib>nm libkernel32.a | findstr CreateFile> > > > 00000000 I __imp__CreateFileW at 28> > > > 00000000 T _CreateFileW at 28> > > > 00000000 I __imp__CreateFileMappingW at 24> > > > 00000000 T _CreateFileMappingW at 24> > > > 00000000 I __imp__CreateFileMappingA at 24> > > > 00000000 T _CreateFileMappingA at 24> > > > 00000000 I __imp__CreateFileA at 28> > > > 00000000 T _CreateFileA at 28> > > >> > > > I think at least THREE calling conventions should be supported --> > > > __cdecl, __stdcall, __fastcall --> > > > but oh well. We can live without __fastcall.> > > > Watcom has another calling convention, "watcall", and they let you> > > > describe calling conventions with #pragmas, neat.> > > >> > > > Thanks,> > > > - Jay> > > >> > > > Share life as it happens with the new Windows Live. Start sharing!> > >> >> >> > Make distant family not so distant with Windows Vista® + Windows > > Live™. Start now!> 
_________________________________________________________________
Watch “Cause Effect,” a show about real people making a real difference.
http://im.live.com/Messenger/IM/MTV/?source=text_watchcause
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080112/744ced82/attachment-0002.html>