On Mon, Sep 27, 2010 at 07:47:48AM -0500, Rick C. Hodgin wrote: > A while back I posted a question about adding edit-and-continue > abilities.
Are you sure that is feasible? I mean, in principle, a caching incremental compiler is probably feasible, but I cannot figure how you could edit the source code of a running process. What should happen when your user add new local variables? > Since then I've begun work on a rapid development compiler > (rdc) which has these abilities, but I've had some thoughts I'd like to > share, and receive some feedback from the GCC experts: > > What if a subset of GCC could be used for this? A portion which uses > the parser to push properly parsed instructions to a new code generator > module which handles the entirety of the edit-and-continue requirements? > I would offer to write these. There has been some experimental work on the idea of incremental compilation, see http://gcc.gnu.org/wiki/IncrementalCompiler & ask Tom Tromey. I believe he arrived to the conclusion it might not worth the effort, but I am not sure at all. You might want to reuse a lot of code from GCC. I would imagine that the front-end & the back-end could be reused, and that your work might become some middle-end pass. If you just want to add some clever middle-end pass, consider perhaps using MELT (see http://gcc.gnu.org/wiki/MELT for more, or ask me) to prototype it. You could use GCC for your goals, which I don't understand well in the detail. It seems that you want to re-edit & recompile code within a running process. But what happens if your user adds a new big variable (e.g. an automatic array) inside a middle stack frame (so changes the call stack)? So my guess is that you are aiming an impossible goal. But perhaps I misunderstood you! > > These abilities would be one part of the other part, which would be > changes to GDB which allow the changes to be updated against the > executable code image in memory. > > The goal here would not be to have ANY code speed, code size, or > anything glorious in the generated code, but would be only a true and > wholly accurate representation in execution as dictated by the original > source code, with all traditional step-through line-by-line debugging > abilities being generated, but with the added new ability to allow > compilation of changed source code, merged into the existing executable > and image in memory without leaving or restarting the app. > > The product I've been developing is a simple C/C++ compiler that > basically does what I've described. It's in early stages, If your product is based upon GCC, it should be a free GPLv3 licenced software (since it is derived from GCC GPLv3 source code). > and it occurred to me that it might be easy or easier for me to add > this new edit-and-continue module to both GCC and GDB, and then have > the existing GCC community reap the benefits of this added feature, > being maintained from here on out -- by me at first, but whoever > else would want to do it at some point. I probably misunderstood your goals, because my feeling is that you would dream of changing the source code of a running C application and incrementally re-feeding it into the running process, and I don't understand how you handle the variation of internal call stack frames, and even what that would mean to your user. If you really want the user to change code and continue running, consiser studying old Andrew Appel's "Compiling with Continuations" book. But that won't work for old C code (unless you radically change the ABI to something very incompatible). Cheers. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} ***
