> Most of the interesting bits happen in the linker+debugger... Agreed, which is why the compiler side doesn't matter much in terms of how much it does, just so long as it is correct and compliant. This is the hard part I'm finding, which is why I'm looking to the GCC community which spends a great deal of effort maintaining that compliance.
The GCC portion (which generates the input to this process which writes the alternate kind of output which accommodates everything necessary to feed the linker and program database with enough information that it may handle multiple compiles over time, etc.) coupled to this new "managing back-end" would enable the ability, when coupled also to changes in gdb which allow it. > What you then need is a linker that will relink an image, changing it as > little as possible relative to a previous run. Your debugger then needs to > be > able to replace these images in-place (which may require interaction with the > dynamic linker). Exactly. That is exactly it. > Be warned that this ends up being extremely complex, even for relatively > simple changes. If the design was implemented in such a way that each source code line or function was contained in its own logical unit, then it becomes a simple matter of replacement. The linker would determine code generation size to see if it could overlay the existing block that was previously at that location before the code change, and if so then overwrite it, adjusting the instruction pointer to the new instruction location in the process, or if it could not, then it would NOP-out everything that's there and insert a branching instruction to some new location tagged on to the end of the executable, which executes the new, larger amount of code, before branching back then to continue in the program where it would've been originally. If you look at the way Microsoft handles this by tracing through the disassembly view, it is very straight-forward, though I agree with you that it can be very complex. - Rick
