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