For a shared library you need a well-defined namespace for GCC functions / variables so it doesn't interfere with users. Are you going to put everything inside a "gcc" namespace or similar? (You also need to avoid host libraries such as libiberty - which have C interfaces - interfering with users of the shared library. If the initial hosts for shared library builds are ELF, I suppose you can do that with a version map to hide everything not in the "gcc" namespace.)
Some observations specifically on your top-40 globals: * global_options: where available, using a pointer to a gcc_options structure is of course better than using a universe (some attributes could be implemented more cleanly if there were per-function gcc_options pointers, for example). Note also the various TARGET_* macros that are generated to AND a variable with a mask - really, such macros should gain a parameter that is a pointer to a struct gcc_options (and then you'd pass &global_options to them if no more specific structure is available). * For dump_file and associated variables such as dump_flags, I sort of think there should be a proper API for code writing to dumps rather than directly accessing dump_file all over the compiler. That should massively reduce the number of places needing to access those fields of the universe. * For targetm, make it const (which would move any further enhancements to it firmly into the domain of Andrew MacLeod's proposal and out of yours, because once it's const it's not global state for a compiler only supporting one target at a time). There are only a few places, for a few targets, that write to targetm at runtime; I think it should be possible to fix those by e.g. changing some data hooks in targetm into function hooks. * For stderr and stdout, really the compiler should only be using them through narrow diagnostic interfaces and not other code using them directly. Put them in global_dc (which would, I suppose, in turn go in the universe)? A shared library user should be able to replace them with streams opened with open_memstream, for example, rather than having diagnostics go direct to stderr/stdout at all. Yes, this requires dealing with implicit uses through functions such as printf as well as explicit references directly in GCC. * For input_location, you no doubt know we want almost everywhere to use the location of some well-defined source-code construct instead of the global (the diagnostic functions that implicitly use input_location should go away completely, for example). But changing that is a lot of work so things probably do need to start by putting it in the universe as you suggest. * For flag_isoc99 and associated variables defined in c-common.c, move them to Variable entries in c.opt (i.e., into global_options). In general, if a variable describes state determined by command-line options, moving it into global_options is probably sensible. * For asm_out_file, see dump_file, stdout and stderr above - there should be a well-defined API for writing assembler output and only the implementation of that API should refer directly to this global. * For lang_hooks, see targetm and make it const. Some hooks are deliberately modified in free_lang_data - the answer to that is, I think, to stop using those hooks directly except via a wrapper that checks whether free_lang_data has been called (one new global) and decides whether to call the langhook based on that. -- Joseph S. Myers jos...@codesourcery.com
