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

[Tony Hosking]

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!