On 28 Feb 2012, at 14:36, Lukasz Sokol wrote:

On 28/02/2012 10:45, Jonas Maebe wrote:

Apple supported that in older versions of their development tools,
and it worked as well (or as badly) with FPC as it did with GCC. It
required changes to their dynamic linker (for the code replacement)
and to GDB. It was extremely flakey and limited though, and they
abandoned it fairly quickly.

(Un)fortunately I don't know much about the internals, as I mentioned :)

The closest idea that looks similar is a loadable library: you can unload a dll (or a .so), edit/recompile/rebuild it while the caller program is paused/waiting, then reload it (with an obvious constraint that you can't modify the interfaces
that the already-running program knows)
- now imagine each code/data block is separate 'object' that can be loaded/unloaded...?

That is basically what Apple did. But if you want to do that at a reasonable speed and with support for e.g. existing addresses in memory (someone may have taken the address of a routine you are about to replace, and if the new code is larger it may get stored somewhere else), then you need lots of extra support (e.g. via trampolines for code; for data it's even harder). Not to mention that your debugger has to be able to deal with code changing addresses all the time and debug info changing.

In the end, people spent more time debugging the inconsistencies and limitations of "fix and continue" than it helped them. Maybe Microsoft's implementation is better, but
a) it is extremely hard to get right
b) as mentioned, it cannot be implemented in FPC itself; it mainly requires support from a lot of other things (and if that support is in place and requires some help from the compiler, then we can talk about making FPC support such an environment)


Jonas
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Reply via email to