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

[Jay]

I commited something LIKE this, that lets m3core.dll link.
 (The below had several errors. Failing to loop, failing to terminate the list correctly, only getting function pointers or functions instead of both, for some reason the Windows *.i3 files use a mix.)
 
libm3.dll has a boring pathname format problem, ld doesn't like c:\foo\../bar.lib and I got sidetracked..
 
It MIGHT not work for SOME functions, a link error -- if taking __int64 or small structs by value, in a __stdcall function.
I'll see if that comes up as I progress through the system slowly.
 
 - 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 19:06:35 -0500> To: jayk123 at hotmail.com> > It will need to be a little cleaner than that -- I'd rather gather > the parameters as declared and enter them into the function type. It > means not ignoring the parameter decls: see m3cg_declare_param check > for current_param_count==0. To do this it needs to be a little bit > smarter about managing current_function_decl -- probably a stack.> > On Jan 12, 2008, at 2:57 PM, Jay wrote:> > > Something like this?????> >> > ===================================================================> > RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v> > retrieving revision 1.41> > diff -r1.41 parse.c> > 3066a3070> > > tree atypes = NULL_TREE);> > 3091c3095,3102> > < TREE_TYPE (p) = build_function_type (return_type, NULL_TREE);> > ---> > > /* for NT386 __stdcall, we just need to declare the right number> > > of parameters> > > */> > > if (--n_params== 0) {> > > atypes = tree_cons (NULL_TREE, t_word, atypes);> > > }> > >> > > TREE_TYPE (p) = build_function_type (return_type, atypes);> >> > haven't even compiled it yet..> >> > - Jay> >> >> >> >> >> >> > > From: jayk123 at hotmail.com> > > To: hosking at cs.purdue.edu> > > Date: Sat, 12 Jan 2008 18:13:27 +0000> > > CC: m3devel at elegosoft.com> > > Subject: Re: [M3devel] could someone add __stdcall name mangling > > to m3cc please?> > >> > > 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> >> >> > Get the power of Windows + Web with the new Windows Live. Get it 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/20080113/d6cafeec/attachment-0002.html>