I've been looking at removing global state from GCC with a view to making it be usable as a shared library.
I've been posting various patches relating to this, but I thought it was time to post a comprehensive plan so you can see how I think it all ought to fit together. You can see an HTML version of my proposal at: http://dmalcolm.fedorapeople.org/gcc/global-state/ and the source for the doc can be seen at: https://github.com/davidmalcolm/gcc-global-state/ (restructured text, using the Sphinx toolchain). I've gone through all of GCC's passes, identifying internal state, and also looked at the most-frequently used global variables in GCC. You can see detailed notes on these in the appendices. It's still a work-in-progress - there are still quite a few TODOs in there, but it seemed time to post to this list. A single-paragraph summary is that I want to move global variables and functions into classes: these classes will be "singletons" in the normal build, and will have multiple instances in a shared library build, allowing for multiple "parallel universes" of state within one GCC process. There are various tricks to (a) maintain the performance of the standard "monolithic binaries" use case and (b) minimize the patching and backporting pain relative to older GCC source trees. In particular, it introduces a new compiler attribute "force_static" which gets used in stages 2 and 3 of the bootstrap to eliminate "this" from methods of the various singleton classes. I hope the plan seems reasonable to the core GCC maintainers, and I'm keen to get moving on this for GCC 4.9. However I appreciate that I'm a relative newcomer to GCC development (albeit the author/maintainer of the gcc python plugin, for the last 2 years). There are various questions e.g. what can go into trunk vs a branch? various naming decisions etc. The "trunk vs branch" question is the one I'm most keen to resolve. In particular, I'm aware that Andrew MacLeod recently posted another architectural proposal: http://gcc.gnu.org/ml/gcc/2013-06/msg00163.html AIUI his proposal and mine are mostly orthogonal to each other: his makes changes to the insides to "tree", whereas mine bundles up global variables and functions into classes. Both proposals involve touching a lot of code but both can largely be done incrementally, and, I hope independently of each other - but I want to avoid painful branch mergers, of course. BTW, I will be at the GNU Tools Cauldron next month. Thoughts? Dave
