Build and run (at least in interp mode...) on MacOS

[tom-seddon]

More for interest/amusement than accepting! - this won't build on Linux any more as it stands...

Changes:

• a few misc bits and pieces: qsort_r nonsense, printf format specifier tweaks, ucontext_t, hack to work around lack of memfd_create
• fix clang as issue: different syntax for stuff like .section rodata
• fix clang as issue: global symbols don't have _ prepended. From reading around it doesn't seem there's any good solution to this, so I picked a bad one that was easy for me to do with some keyboard macros while watching TV
• replace jCC 0 with jCC dword ptr LABEL when forcing a long branch
• remove shm ID after XShmAttach, not before
• poke at build script. It now assumes MacOS+the MacPorts package manager - this definitely won't work on Linux, it definitely won't work with the (much more popular) MacOS package manager Homebrew, and it 100% needs some attention

Stuff still to do:

• JIT doesn't actually work
• make non-debug build work
• fix keyboard (the X keycodes are totally different on MacOS)
• try running the tests and see what happens
• figure out what the dependencies are, exactly - you'll need at least XQuartz and the X11 librarles
• etc., etc.

Thanks,

--Tom

[scarybeasts]

Thanks for looking into this Tom! This is so cool!

To start getting bits landed, would you be willing to split into multiple relatively independent PRs? (That's my personal way of preferring to work.) Some pieces stand out as being suitable for splitting out and landing right away:

• "replace jCC 0 with jCC dword ptr LABEL when forcing a long branch" Because of this, the Linux build also fails with clang. If you could use capital DWORD PTR to keep with existing style, that PR should be good to go right away.

• "remove shm ID after XShmAttach, not before" This is just generally more correct! :) I do get strange X errors on rare occasion when running the test; maybe it's the same thing. The added XSync should have its error code checked. Once this is landed, I'll likely rename os_window_linux.c to os_window_posix.c since it covers more than just Linux.

• "printf format specifier tweaks" Again, just generally more correct, thanks.

• "qsort_r nonsense" Wow, I had no idea! Given the beebjit rule of no ifdef's in .c files, I'd suggest we use the existing paradigm for os-specific stuff. i.e. add os_sort.h with a sane API and then have os_sort_linux.c and os_sort_osx.c. Let me know if you want me to lay the groundwork for that once since it's my fault for using qsort_r!

• "the X keycodes are totally different on MacOS" Oops, sorry, that's my mess. I had no idea. Would you like me to add platform pluggable keycode tables? I can add another os_blah.c selector to os.c, perhaps.

[scarybeasts]

One further comment on the "jCC 0" fixes, having thought about it some more. Would it make sense to have them all jump to the same place, along the lines of "jb DWORD PTR asm_x64_jit_unpatched", where asm_x64_jit_unpatched would have the body of "int 3" or "ud2" or something like that. This would seem to offer a couple of benefits: a) Easier to copy/paste and b) Failure to actually patch up any of the jump targets will fail more readily and clearly.

[tom-seddon]

Certainly - now I know this stuff is actually going to work, it would make more sense to redo it in multiple parts!

I'm happy to leave qsort_r to you, and I'll just follow along. Same with the keycodes. I can do the rest.

Regarding jcc 0 - I assume the dword ptr does work in gas in Intel mode?

--Tom

[scarybeasts]

DWORD PTR should be good -- existing code seems to variously use DWORD PTR, WORD PTR and lots of BYTE PTR!