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 entr
On 18 July 2010 23:15, Rick C. Hodgin wrote:
> Jonathan,
>
> If you run Linux, you can download VMware, and install a version of
> Windows XP or later)
I don't have a licence to do that.
> and download Visual Studio Express from Microsoft
> for free. You can experiment with it and see how usefu
Jonathan,
If you run Linux, you can download VMware, and install a version of
Windows XP or later) and download Visual Studio Express from Microsoft
for free. You can experiment with it and see how useful it is. It's
pretty darned amazing actually. Once you use it, you'll always miss it.
Simple
On 18 July 2010 20:52, Rick C. Hodgin wrote:
>
> 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
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
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:
