Some useful information from #mingw-w64, <ktietz> fs-a long type is on w64 ABI 32-bit, the calling convention is different (which means argument passing and register usage). variadic is different to linux64, and well underlying C runtime is of course different, too
<fs-a> What's different in variadic? (high level) <ktietz> from high-level there is no difference. The difference is on x86_64 variadic is kept in structure, but for w64 it remains passed directly on stack <ktietz> like for 32-bit <ktietz> therefore each call on w64 has a reserved stack area of 32-bytes, which is used for variadic to store register passed arguments into <ktietz> gnu C allows as extension always inline assembler. For 64-bit and for 32-bit windows targets. Maybe you need to use '__asm__' or type a '__extension__' in front of the asm-keyword, if you are using strict ISO-C <ktietz> see for calling convention msdn or http://sourceforge.net/apps/trac/mingw-w64/wiki/MinGW%20x64%20Software%20convention <@ktietz> also a difference of w64 in comparison of x86_64 (sysv) is, that the stack after function eplilogue gets always aligned to a 16-byte alignment <jon_y> ktietz: is there a sysv_abi or some such attribute? <@ktietz> yes, there is <@ktietz> on linux64 you can use function attribute "ms_abi", on w64 you can use "sysv_abi" function attribute. By this you can switch calling convention for a function <jon_y> ktietz: is it safe to use sysv_abi on the prototypes? eg for inline asm functions designed for linux sytems <ktietz> in general yes. But you should make sure that this attribute is on prototype for any call for such a function. Otherwise it could fail badly. An unprotyped call uses always *default* calling convention <jon_y> ktietz: nice, when was sysv_abi introduced? <ktietz> oh, IIRC about 1 year ago <jon_y> in 4.4.x? <ktietz> yes, 4.4.x supports it already <jon_y> ok, thanks <ktietz> I did this for the Wine people 2010/2/8 Michael Menegakis <[email protected]> > This is a pack to compile an 64bit binary of ioq3 on win64 very easily so > one can go directly to debugging. I can't find the reason vm_ 2 is not > functional hence I request help. (vm_ 0 and 1 appear playable); vm_ 2 goes > out with "ERROR: Bad UI system trap: 98498432[or other similar undefined > number]" in default baseq3 and mods. > > http://www0.org/urt/ioq3+mingw64.tar.7z > (it also has a built .exe with debugging symbols; it needs the 64bit SDL > DLL included) > > How to build: > - Unpack the two directories into msys home > - Set mingw64 as /mingw in /etc/fstab > - make debug > > To use: > - SDL.dll 64bit is included (build from 1.2.14 release) - remember to > replace the 32bit one. > - (pack also has a built .exe with debugging symbols) > > vm_86_64 info > - vm_x86_64.c is modified to use Microsoft's mem allocation mirroring > vm_x86.c > - both on it and vm_x86_64_assembler.c, long is replaced with int64_t, > intptr_t or long long. > - ___feel free to delete them and replace them with upstream's to start > anew___. > - there's a malloc equivalent of mmap in it from upstream that when used it > doesn't reach the 'Bad UI system trap' error but segfaults at __asm__ > __volatile__ () of vm_x86_64.c > > Other information: > - Makefile is modified to support x86_64 COMPILE_ARCH (platform stays > mingw32); it's for now explicitly set. With mingw64 it just works for now. > - sdl .a libs are included in libs/win64 and Makefile is ready for it > - mingw64 bin dir has gdb. > - mingw64 build is > http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-w64-bin_x86_64-mingw_20100123_sezero.zip/download > > Please help! >
_______________________________________________ ioquake3 mailing list [email protected] http://lists.ioquake.org/listinfo.cgi/ioquake3-ioquake.org By sending this message I agree to love ioquake3 and libsdl.
