I was out for a few days working my butt off so I can graduate (whew!), so I haven't been around to clarify some things, but hey.
hector wrote:Just a note regarding the linker flag -read_only_relocs:
With this set to suppress, the wrappers for getchar, putchar and also malloc can be removed.
However, this flag can also hide errors that crash zsnes. If the following change is reverted
Code: Select all
Index: uic.c
===================================================================
--- uic.c (revision 3234)
+++ uic.c (working copy)
@@ -133,7 +133,7 @@
}
void *malloc_ptr;
-unsigned int malloc_size;
+unsigned int malloc_size = 0;
void malloc_help()
{
malloc_size appears as a common symbol in uic.o rather than a data symbol. During linking, an error is normally produced that _malloc_size is a read-only relocatable symbol. This actually seems to happen because the linker can't find _malloc_size in uic.o for some strange reason. If this error is suppressed the resultant zsnes will crash with a bus error. BRPXQZME, I believe the bus error you experienced was for this very reason. In your case the fix would be the above patch.
I added that back in when I realized it had fallen out of my patchset, but yeah... since it's renamed in SVN to not be a special name, it's fixed. At least now I know what that means....
hector wrote:Thank you Nach for the commits. I don't want to seem ungrateful, but will you also consider committing the change to the LDFLAGS (-read_only_relocs suppress), and adding and using the function sdl_keysym_to_pc_scancode().
I question the wisdom of having that flag in there by default, or at least keep it at warning, since this does reveal things like the malloc_size function name conflict, at least (not that it's likely to happen again).
Nach wrote:hector wrote:
will you also consider committing the change to the LDFLAGS (-read_only_relocs suppress)
This flag sounds to me like Apple knows they have a bug with their linker / or objects generated by some of their compilers, and added a flag to work around it.
If I'm mistaken, please tell me so. Using this flag creates working binaries?
It's not really a bug, just an undesirable. In fact, Gentoo Linux users see a similar complaint whenever they compile something with one of these, some confusing technogarble about TEXTREL in a QA warning or something like that (and especially when you use a binary-only driver). It makes things go a little slower, but on the other hand it's just one freaking function call. Computers like to not have to find things to use them, so by making a wrapper function you sacrifice efficiency for certainty (by not making it have to fill in the address). It has made working binaries for me, it's just a cheap trick I used to force the compiler into continuing past something it wants you to stop at. But I still think it should be at "warning" instead of "suppress", just so nothing else slips under the radar.
Deathlike2 wrote:All of the filters you have mentioned require MMX (which have been available in Intel processors since 1996).. there's a possible chance that the NASM compiler for the Mac is probably retarded when dealing with MMX instructions.. you might want to look into it.
Pretty much anything I've tried to compile for Intel OS X gets annoyed at the MMX code more than anything else. Wonder why, but it's the truth. But I don't know how well NASM handles it; all those other things were choking with GCC inline assembly.
EDIT: forgot to mention. Hector, awesome stuff.
EDIT2: So I did a recompile with all the latest info except Hector's last post, and now I get the code alignment error for the first time ever... hm. Doesn't stop the show, so I guess we wait for nasm to be fixed if we're too lazy to patch it ourselves.... I will have the patch up soon once (if?) the school's connection lets me in.
EDIT3: Uh ohs. Attempts to run r3259 with the current patches results in not just a Code Alignment Failure, but also pretty much graphics being either black or messed up in most games (well, Star Fox actually causes a Bus Error). Since I did just ram through a lot of revisions, I'm not too sure everything went smoothly.