Rick,
You are seeking perfection while I am suggesting a technique that
doesn't capture all
cases but is useful:
1) change only the body of a function
2) compile the new function into a shared library which the
debugger dlopen's
into the target process.
3) replace the entry-point code of the old function with a branch
to the new version.
On 7/18/2010 12:52 PM, Rick C. Hodgin wrote:
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
