On Sun, 2010-07-18 at 19:46 +0100, Jonathan Wakely wrote:
> On 18 July 2010 16:25, 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.
> >
> > The resulting changes are passed to gdb for insertion into the running
> > program's memory in real-time.
>
> That might be harder to do for optimised code, where there isn't
> necessarily a direct correspondence between individual source lines
> and executable code. IIUC Visual Studio will only debug unoptimised
> code, gcc doesn't have the same distinction between "debug build" and
> "release build" - you can debug optimised code. It would also need
> more integration between gcc and gdb than currently exists.
Jonathan,
Visual Studio will debug optimized code, but it is difficult to do
because of the loss of 1:1 ratio between source code and executable
instructions. This is especially difficult in mixed-mode where you see
source code alongside disassembled machine code (assembly instructions).
Plus, the VS optimizations move loop tests to unusual locations for the
target CPU, etc. But edit-and-continue is always available in Visual
Studio if the original program database was specified when last
compiled.
The integration would have to be added, but if we can produce through
gcc (and ultimately g++) a fixed kind of output that describes "what's
changed" since it was re-compiled, then it would be easy to add those
features to gdb, because the only ones required would be:
1) Update to a memory table for function offsets
2) Update to global memory space to move old variables to new
locations
3) Update to local memory space to move old variables to new
locations
4) Ability to add new global, local memory variables.
5) Ability to add new functions to the table.
Everything else should just be loading the newly changed functions to
some location in memory that gdb will likely assign, so as to derive its
location for the memory-based table, and to leave everything that did
not change where it was.
To be clear: I'm talking about creating this ability to generate
function call code that does not directly call its target function
offset, but instead calls a known location in memory that is rigid and
unchanging always, which itself references either dynamically updated
code as needed, or calls a reference into a memory-based table which
points to the new function locations.
Just my thoughts.
- Rick C. Hodgin
