Still todo:
- Use own version of OpenAL (system one on the DTK appears to be flakey...may be fixed for retail 10.4.4 on the actual shipping Macs, though.
- Fix asm code (or just remove it outright). See FIXMEs in the patch.
--ryan.
asm errors, at Angst's request:
../unix/qasm.h:37:Unknown pseudo-op: .extern
../unix/qasm.h:37:Rest of line ignored. 1st junk character valued 115 (s).
../unix/qasm.h:38:Unknown pseudo-op: .extern
../unix/qasm.h:38:Rest of line ignored. 1st junk character valued 112 (p).
../unix/qasm.h:39:Unknown pseudo-op: .extern
../unix/qasm.h:39:Rest of line ignored. 1st junk character valued 115 (s).
../unix/qasm.h:40:Unknown pseudo-op: .extern
../unix/qasm.h:40:Rest of line ignored. 1st junk character valued 115 (s).
../unix/qasm.h:41:Unknown pseudo-op: .extern
../unix/qasm.h:41:Rest of line ignored. 1st junk character valued 115 (s).
../unix/qasm.h:42:Unknown pseudo-op: .extern
../unix/qasm.h:42:Rest of line ignored. 1st junk character valued 115 (s).
../unix/qasm.h:43:Unknown pseudo-op: .extern
../unix/qasm.h:43:Rest of line ignored. 1st junk character valued 118 (v).
../unix/qasm.h:44:Unknown pseudo-op: .extern
../unix/qasm.h:44:Rest of line ignored. 1st junk character valued 118 (v).
../unix/qasm.h:45:Unknown pseudo-op: .extern
../unix/qasm.h:45:Rest of line ignored. 1st junk character valued 118 (v).
../unix/qasm.h:46:Unknown pseudo-op: .extern
../unix/qasm.h:46:Rest of line ignored. 1st junk character valued 66 (B).
../unix/ftola.s:36:Unknown pseudo-op: .float
../unix/ftola.s:36:Rest of line ignored. 1st junk character valued 48 (0).
../unix/ftola.s:66:Unknown pseudo-op: .global
../unix/ftola.s:66:Rest of line ignored. 1st junk character valued 113 (q).
../unix/ftola.s:78:Unknown pseudo-op: .global
../unix/ftola.s:78:Rest of line ignored. 1st junk character valued 113 (q).
../unix/ftola.s:92:Unknown pseudo-op: .global
../unix/ftola.s:92:Rest of line ignored. 1st junk character valued 113 (q).
../unix/ftola.s:107:Unknown pseudo-op: .global
../unix/ftola.s:107:Rest of line ignored. 1st junk character valued 113 (q).
../unix/ftola.s:121:Unknown pseudo-op: .global
../unix/ftola.s:121:Rest of line ignored. 1st junk character valued 113 (q).
../unix/ftola.s:137:Unknown pseudo-op: .global
../unix/ftola.s:137:Rest of line ignored. 1st junk character valued 81 (Q).
../unix/ftola.s:150:Unknown pseudo-op: .global
../unix/ftola.s:150:Rest of line ignored. 1st junk character valued 81 (Q).
make[2]: *** [release-darwin-i386/ded/ftola.o] Error 1
Created attachment 831[details]
Updated patch with asm support.
Ok, I got it now, I think.
I read Apple's manual for the assembler, and it appears they have the directives we need, just different spellings (.globl instead of .global and .single instead of .float)...newer gas versions should support these older names, so I'm just switching them.
Also had to toggle the name mangling to behave as MingW32 does...Mac OS adds the underscore before symbol names. Now the asm code is working.
Make sure this patch doesn't break Linux and submit it.
--ryan.
The x86 vm crashes when built with gcc-4.0 on OS X. The asm handling in gcc-4.0 seems to be broken in a couple of ways:
1) asm() doesn't appear to be able to jump to a function like has been done in AsmCall(). This causes a crash with signal EXEC_BAD_ACCESS. This fix was taken from the http://www.sqonk.com.au SVN
2) Once the vm was loaded it would fail immediately with "ERROR: opStack corrupted in compiled code". There seems to be some issue with the __asm__ handling when the same address is in both the input and output operands. Changing the output to a different variable seems to have fixed this.
Don't apply this patch yet, I still haven't done a real OSX intel test, just on darwinx86. This will also have to be tested on other x86 platforms (it does seem to work on linux with gcc 3.3)
Created attachment 936[details]
apple gcc-4.0 asm workarounds
Oops, my last patch didn't really work under linux-x86 like I thought it did.
"2)" had nothing to do with the use of the same address for input and output operands, it had to do with the variables being declared static. Apple's gcc seems to require that they are NOT static, and gcc-3.3 on linux seems to require that they are static.
This patch addes a #ifdef for __APPLE_CC__ since it's starting to look like this is the only system with the issue.
(In reply to comment #10)
> Created an attachment (id=936) [edit]
> apple gcc-4.0 asm workarounds
I have reports that this still doesn't work in intel macs :(
I finally figured this out. The seems to come from MMX instructions being used by apple's gcc by default (and even if -fno-mmx is used). When these MMX instructions were used in-between the __asm__ call.
The crashing was difficult to debug since most often it was happening inside builtins (e.g. ceil() and strncmp()) which are always used from libSystem.dylib (libm) despite being called "builtin". The debuger would choke here since libSystem.dylib has no debug symbols and libSystem_debug.dylib does not appear to work.
I finally found a non builtin crash in botlib/l_script.c which did an implicit
conversion of a unsigned long int to double:
*floatvalue = *intvalue;
This used a set of MMX instructions and would crash on an Illegal instruction when it tried to write the frame pointer (%%ebp) with movapd.
I first tried to push/pop the frame pointer to the stack in asm like is done
in the win32 version and although I could prevent this crash the builtin's were still crashing. There is no "naked" attribute and __LOCAL_SIZE in gcc, so there was no way to guess how far to pad the stack.
Then I found the gcc flag -mstackrealign:
-mstackrealign
Realign the stack at entry. On the Intel x86, the -mstackrealign
option will generate an alternate prologue/epilogue that realigns
the runtime stack. This supports mixing legacy codes that keep a
4-byte aligned stack with modern codes that keep a 16-byte stack
for SSE compatibility. The alternate prologue and epilogue are
slower and bigger than the regular ones, and they require one dedi-
cated register for the entire function. This also lowers the num-
ber of registers available if used in conjunction with the "reg-
parm" attribute. Nested functions encountered while -mstackrealign
is on will generate warnings, and they will not realign the stack
when called.
This fixes the issue completely which really pisses me off since I _know_ I tried it on a whim countless hours ago, but I must have not done a full compile because it still crashed :(
Anyway, it's possible that this flag may be required on other x86 targets as well once gcc-4.0 sees wider use.
Setting a QA contact on all ioquake3 bugs, even resolved ones. Sorry if you get a flood of email from this, it should only happen once. Apologies for the incovenience.
--ryan.
Created attachment 829 [details] Patches to get game compiling.Created attachment 830 [details] Alternative Intel OS X patchCreated attachment 831 [details] Updated patch with asm support. Ok, I got it now, I think. I read Apple's manual for the assembler, and it appears they have the directives we need, just different spellings (.globl instead of .global and .single instead of .float)...newer gas versions should support these older names, so I'm just switching them. Also had to toggle the name mangling to behave as MingW32 does...Mac OS adds the underscore before symbol names. Now the asm code is working. Make sure this patch doesn't break Linux and submit it. --ryan.Created attachment 935 [details] apple gcc-4.0 asm workaroundsCreated attachment 936 [details] apple gcc-4.0 asm workarounds Oops, my last patch didn't really work under linux-x86 like I thought it did. "2)" had nothing to do with the use of the same address for input and output operands, it had to do with the variables being declared static. Apple's gcc seems to require that they are NOT static, and gcc-3.3 on linux seems to require that they are static. This patch addes a #ifdef for __APPLE_CC__ since it's starting to look like this is the only system with the issue.I finally figured this out. The seems to come from MMX instructions being used by apple's gcc by default (and even if -fno-mmx is used). When these MMX instructions were used in-between the __asm__ call. The crashing was difficult to debug since most often it was happening inside builtins (e.g. ceil() and strncmp()) which are always used from libSystem.dylib (libm) despite being called "builtin". The debuger would choke here since libSystem.dylib has no debug symbols and libSystem_debug.dylib does not appear to work. I finally found a non builtin crash in botlib/l_script.c which did an implicit conversion of a unsigned long int to double: *floatvalue = *intvalue; This used a set of MMX instructions and would crash on an Illegal instruction when it tried to write the frame pointer (%%ebp) with movapd. I first tried to push/pop the frame pointer to the stack in asm like is done in the win32 version and although I could prevent this crash the builtin's were still crashing. There is no "naked" attribute and __LOCAL_SIZE in gcc, so there was no way to guess how far to pad the stack. Then I found the gcc flag -mstackrealign: -mstackrealign Realign the stack at entry. On the Intel x86, the -mstackrealign option will generate an alternate prologue/epilogue that realigns the runtime stack. This supports mixing legacy codes that keep a 4-byte aligned stack with modern codes that keep a 16-byte stack for SSE compatibility. The alternate prologue and epilogue are slower and bigger than the regular ones, and they require one dedi- cated register for the entire function. This also lowers the num- ber of registers available if used in conjunction with the "reg- parm" attribute. Nested functions encountered while -mstackrealign is on will generate warnings, and they will not realign the stack when called. This fixes the issue completely which really pisses me off since I _know_ I tried it on a whim countless hours ago, but I must have not done a full compile because it still crashed :( Anyway, it's possible that this flag may be required on other x86 targets as well once gcc-4.0 sees wider use.