Terrence, Procedure entry points, global and local variable locations in memory, structure definitions and offsets, etc. These would all have to be updated as changes are made, and that means each reference used in the executable would need to be updated, and that could mean several source files are recompiled with a single change which affects it. And if there are shared resources loaded, each of those would have to be updated as well, that is if we wanted to go "whole hog" like that. Otherwise, we could limit the changes to only the currently-executing program.
The idea of having function entry points across the board for all executed code would be required, allowing those links to be updated dynamically at run-time. We could even use a memory-based lookup table that's updated by gdb to the new entry points for the executable code. It would be slower for execution, but for development the time savings would be there because changes could be made on the fly, recompiled, memory variables changed as needed, and then continue execution without restarting the entire app. The ability would also have to be created to allow local variable re-mapping across these updates, so that if the stack changed, the data on the stack is migrated from its old locations to the new ones. This would be a table built by gcc that's passed to gdb for each function, where gdb updates the stack in that way. If parent functions on the call stack were updated, they would have to be altered on the stack as well. This could be accommodated by automatically including a specified amount of "extra space" in local variable space per function entry point, something like 32 bytes (eight 4-byte variables) by default, with a compiler switch to increase that block size. This extra space would allow for a certain number of new variables before a full recompile is required again. We could also have #pragma-like statements for individual functions where we know some heavy changes will be used, to give them an extra 512 bytes, or whatever's specified. - Rick C. Hodgin On Sun, 2010-07-18 at 12:36 -0700, Terrence Miller wrote: > If you are willing to restrict edit-and-continue to whole procedures > then minimal changes to the compiled > code for procedure entry points is all that is required (well that and > dlopen). > > Terrence MIller > > On 7/18/2010 12:14 PM, Dave Korn wrote: > > On 18/07/2010 16:28, Robert Dewar wrote: > > > >> Rick Hodgin wrote: > >> > >>> Ian, > >>> > >>> The idea is to create a program database of the compiled program on a > >>> full compile. Then when asked to re-compile with the > >>> edit-and-continue switch, it only looks for changed code and compiles > >>> those few lines. Everything else it needs to carry out compilation is > >>> there from previous full-compile as was originally parsed, or from > >>> subsequent edit-and-continue compiles which updated the database. > >>> > >> Unlikely to be feasible in my view without slowing down compilation > >> substantially. > >> > > I think you're probably assuming too much. Tom T. is working on an > > incremental compiler, isn't he? I expect that that and LTO between them > > would > > / could give us all the tools we needed to make an EAC-friendly compiler. > > > > But yes, OP, it's a long-term project. > > > > cheers, > > DaveK > > > > > > > >
