PCSX2 meets clang
So I posted in the developer interest thread, but I figured I could go ahead and make a thread so I don't pollute the developer interest thread with stuff pertaining to what I'm doing.

Anyway, I'm currently working on getting PCSX2 and all plugins to build with clang. For those of you who don't know, clang is part of the LLVM project, an incredibly promising compiler tool suite that has a lot of advantages over GCC. Unfortunately switching compilers isn't trivial. PCSX2 has a bunch of hacks that only work on GCC and MSVC. Build errors are easy to fix, in fact I've finished all of the trivial ones and have gotten everything to build with clang. Runtime errors are not easy to fix.

Here's the status:
- Nearly everything builds with clang (I can build all projects with some build hacks. Specifically, selectively compiling some .S and .cpp files to compile with GCC, usually due to assembly stuff)
- Clang built plugins work well with GCC build PCSX2 (pad, GSDX, and zeroSPU all work very well in my single test of Kingdom Hearts)
- Clang built everything can boot the PS2 bios with glitchy graphical output using all intrpreters. Right now I'm getting segfaults with recompilers. Kingdom Hearts boots, but I have to do some debugging black magic to get it to do so.

I'm also working on adding updated Code::Blocks IDE workspace and project files; one set for clang and one for GCC. I prefer to work and build everything inside an IDE, so these are mostly for my own benefit. If I get them cleaned up and remove the hacks to get PCSX2 to build with clang then I might send them upstream.

Anyway, if anyone want's to check out the code, it's at https://github.com/Urisma/pcsx2.

Sponsored links

Nice jobs. If you could split commit properly it would be much better for future review.

If it can help you to split the commit.
1/ The theory (your code move will be annoying because you will need to move back manually)
a/ backup the repository (cp -a pcsx2 pcsx2_bck)
b/ with rebase -i => set edit to the commit you want to edit.
c/ uncommit current commit (or git rebase) => git reset --soft HEAD~1
d/ unstage => git reset HEAD --
e/ Lots of command use -p to apply the command to a subcode modification. Use ? to have the details of the interactive prompt.
git add -p (to only add the the part you want)
If you want to drop some code (WARNING IT WILL BE LOST) git co -p --

1/ The pratical case. Do step a/b/c/d. Then you will to manually move back your change to the good file. For example you copy past the option into the build paramaters. Then you git add -p the change. Then you commit (it will only apply to the staged part), if you want to see exactly what you commit. you can do a diff of the staged area with git diff --cached

By the way use only -O0 build.
And don't use GSdx yet. Use another GS plugins.

Edit: I commit several clang warning fix on PCSX2. I would advice you to rebase on it. It would reduce the warning mess and speedup a bit the compilation for you Smile
Ok, I did some history rewriting to separate out clang fixes from CodeBlocks IDE stuff as to keep separate things in separate commits. Everything builds alright with some hacks to build certain files with GCC. PCSX2 segfaults upon writing to the recompiled code cache (not on every write, though, interestingly), so this will be lots of fun to debug.
Cool. I will give it a look. For asm, it might be a good idea to port it on thr gas syntax (at least one that is inlined in middle of file).
Sigsegv are normal. Long story short check gcc behavior.
Gsdx might crash because of some strange alignment issue. Others part coud crash if you have removed a -fno-strict-aliasing
So it seems like the sigsegvs are not being caught by PCSX2's internal handler for some strange reason. Ignoring them in gdb fixes that. Clang seems to be outputting bad code in zeroGS and zzogl. Both plugins cause SIGILL upon trying to start a game. GSDX works, though. I would use GSnull, but I was getting some undefined export errors upon loading it in the plugin selector. That should be an easy fix (I managed to break and fix ZeroGS with the same error, so I know what to look for). I've got -fno-strict-aliasing everywhere it should be. I'm going to try and get cmake integrated with Codeblocks once those cleanups are done so that I don't have to worry about project settings while still having IDE features.
Kingdom Hearts boots with everything built from clang with all the recompilers! Woo. Of course the x86 hacks to build with GCC are still there so those need to be fixed. And optimizations cause WX to bail out on startup of PCSX2 so I'm running on -O0. And I have to run it inside GDB in order to handle SIGSEGVs that happen to not get handled by PCSX2's internal handler. It's something!
Truely a great jobs Smile

Maybe there are some ifdef that depend on gcc builtin Try to grep gnu or gcc.
It seems like clang just doesn't like a lot of the assembly syntax that exists. Everything under the PCSX2 tree builds with clang. The problematic assembly stuff is in the Utilities tree, and all it is is some fast reimplementation of the standard library. I think reimplementation of the standard library is not good at all, so I'd really prefer to ifdef the stuff so that the clang version just uses builtin stand library functions. The usage of these functions is also a pretty big clusterfuck; There's 3 different memcpy versions and 5 different names for them and all of them are used in different places. I'd prefer to just clean it all properly and utilize the standard library where possible, even if it does mean losing some amount of speed. This should hopefully also lessen the sensitivity to optimization flags.
I search a bit on internet. It seems clang support some kinds of Intel syntax but that not very clear. Maybe we can ask them in a mailling list.

Otherwise would it be possible to move ASM in 1 or severals .S files and compile them separately?

Anyway, reimplementation of a standard library function is safe. The voodoo parts are inside the recompiler Wink The goals of std lib is to reduce program complexity but with a "slower" speed. And 99% times it is really worth it (and it always faster than a silly implementation).

Users browsing this thread: 1 Guest(s)