what about a compiler probe?

[Basile STARYNKEVITCH <basile at starynkevitch dot net>]

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} ***