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

[Tony Hosking]

I will be able to get m3cc to spit out the appropriate stdcall  
function names.  Needs a little work, but nothing too drastic.

On Jan 12, 2008, at 1:13 PM, Jay wrote:

> 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. Learn more