Dear All, I am considering implementing the following feature into GCC using the patch on http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01769.html : a compiler probe which permits to probe the run of a compilation, e.g. by displaying in emacs or a graphical GTK application the current pass, Gimple representations, etc... which effectivly probes inside the compiler; this could be useful for long-lasting compilations (in particular those considered in the globalGCC project http://gcc.gnu.org/ml/gcc/2006-10/msg00676.html which will probably "compile" tens time slower than current gcc) of more than several minutes, or for GCC hackers which want to debug or understand its internal by experimenting it. For example, it could be useful to know the currently compiled function, or the current Gimple trees for it, etc... In general do you feel that such a feature could be useful? (it somehow generalize Sebastian Pop's gcc/tree-browser.c)
I propose a --enable-compiler-probe flag to configure which by default is disabled. When GCC is configured with --enable-compiler-probe (which is only possible on some Posix or Unix hosts like linux & BSD & Solaris), the resulting compiler accepts a -fcompiler-probe flag; in the usual case where this flag is not passed, the compiler does not behave differently than usual, except probably a minor performance hit (which won't happen when configured with --disable-compiler-probe). when given the -fcompiler-probe flag, it should get an a string option with it. If this string is a (Unix) file path it indicate a Unix socket or FIFO; if it starts with a vertical pipe bar | it starts the command and communicate with it thru pipes. Typically the command is some client application (either a GTK graphical interface, or an Emacs, or perhaps a FastCGI) which communicates with GCC thru a textual protocol to be defined and documented. The textual protcol should permit to examine, but not change, the compilation state. For a lenghtly static analysis, it could be used to show the properties the compiler currently know about a given (compiled) source point. Since I don't want to add multi-threading into GCC, my plan is to implement this (only on Linux & BSD hosts!) by using old asynchronous I/O, ie the F_SETOWN fcntl, the select system call, so that when some input arrives on the channel, some routine might parse the input and respond accordingly. The dirty trick is to have some volatile sig_atomic_t varible which is set (by a SIGPOLL handler) and routinely checked /* set by SIGPOLL on input */ extern volatile sig_atomic_t comprob_interrupted; The difficult part is to implement the probing routine void comprob_compiler_probing(const char*file, int line); I assume that the probed state is in some global GCC variables. Otherwise, we need more arguments to pass them. Then at appropriate places within the compiler the following macro is called #define comprob_maybe_probe() do{if (comprob_interrupted) \ comprob_compiler_probing(__FILE__,__LINE__): } while(0) And then we could add many calls to the above macros. This is not pretty, but in my experience on other software works quite well. and is not that much intrusive (except in the source by addition of many occurrences to this macrfo, and which executing by testing quite often a volatile variable). Feel free to tell me that it is a crazy idea. But remember that the context is long-lasting compilations. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faïencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} ***