Announce: Fork with rewritten compiler wrapper
Dead2 opened this issue · comments
Yes, this is a little shameless self-promotion, but hopefully for the good of the project.
Because this project has not been maintained for years, and there is a fragmented fork network with mostly half-working versions of Stabilizer, I have taken it upon myself to fork this project and will try to actively maintain it. Note: @ccurtsinger has not endorsed this in any way.
I have made some changes in my fork however.
One of the biggest hurdles for anyone wanting to test Stabilizer with their own application is that szc will fail even the most basic CMake or AutoConf compiler detection. Therefore, before anyone can even test this they might have to do a big rewrite of their applications build system, that would be very hard for bigger projects like Chromium for example.
Therefore I have rewritten the compiler wrapper from scratch, and renamed it to szcc. Now most compiler detection code will succeed, and can it often be used as a drop-in compiler "replacement" for many applications. There are still corner-case bugs, for example I know that gbench fails to compile, and I will accept PRs to fix these if you have the interest and time to contribute.
This makes it a lot easier for anyone to test Stabilizer without investing a lot of time and effort into it before even being able to do anything basic with it.
Unfortunately although Stabilizer has been attempted ported to newer versions of LLVM, and compiles with those, it is causing crashes. Probably the porting effort has been best-effort and is just incomplete. Cudos to @Fusilet @dendibakh @jgall @magras @timadye and others for their efforts though.
One major problem for me is that I do not know how LLVM-pass stuff works at all, so while I have been looking at that code to attempt to find the culprits of the Code Randomization and Stack Randomization crashes, I have very little idea what I'm even looking for. One of those issues has been documented in Issue 1 on my fork so that anyone interested can read up on the symptoms, if anyone has anything to contribute to that analysis or even better a bugfix then that is greatly appreciated.
Hopefully now that Stabilizer is easier to use, it will also be easier to find someone interested in contributing fixes.
In other words, I will attempt to actively maintain the repo and fix any issues that I am able to, but I will also need help to fix some of the Stabilizer functionality. I intentionally broke the Github fork-tree so that it will be less confusing and easier to find up-to-date forks, this Github feature is really not great when the parent project has gone dormant.
If @ccurtsinger wants to become an active maintainer of Stabilizer again, I will happily step aside. My main interest and motivation is that this amazing tool becomes more useful to all the open-source projects out there. If @ccurtsinger would contribute some insight into what the crash bugs are likely caused by, that would be really awesome of course 😉.
Please have a look at the readme of my fork for more information about the changes I have made https://github.com/Dead2/stabilizer
I love the project and would love to help (I have some LLVM dev experience) but there is too much on my plate right now. I will share this with my network, maybe anyone would be interested to help out.