Re: Edit-and-continue

Re: Edit-and-continue

[Rick Hodgin]

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.

On Sun Jul 18th, 2010 2:45 AM EDT Ian Lance Taylor wrote:

>Rick Hodgin <foxmuldrster@yahoo.com> writes:
>
>> To my knowledge, GCC does not currently support any edit-and-continue abilities.  Is this still true?  And if so, are there any plans to introduce it at some point?
>
>I don't see how it makes sense to add edit-and-continue to gcc.
>Compilation times are too slow, but they aren't *that* slow.  Are you
>thinking about gdb?  Or the linker?
>
>Ian

Re: Edit-and-continue

[Robert Dewar]

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.

Unlikely to be feasible in my view without slowing down compilation
substantially.
> 
> The resulting changes are passed to gdb for insertion into the
> running program's memory in real-time.
> 
> On Sun Jul 18th, 2010 2:45 AM EDT Ian Lance Taylor wrote:
> 
>> Rick Hodgin <foxmuldrster@yahoo.com> writes:
>> 
>>> To my knowledge, GCC does not currently support any
>>> edit-and-continue abilities.  Is this still true?  And if so, are
>>> there any plans to introduce it at some point?
>> I don't see how it makes sense to add edit-and-continue to gcc. 
>> Compilation times are too slow, but they aren't *that* slow.  Are
>> you thinking about gdb?  Or the linker?
>> 
>> Ian

Re: Edit-and-continue

[Jonathan Wakely]

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.

Re: Edit-and-continue

[Ian Lance Taylor]

Rick Hodgin <foxmuldrster@yahoo.com> writes:

> 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.

This idea is related to Tom Tromey's incremental compiler work
(http://gcc.gnu.org/wiki/IncrementalCompiler) and to Per Bothner's
compiler server work
(http://per.bothner.com/papers/GccSummit03-slides/index.html).  Neither
project is currently active.  I believe that Diego Novillo is currently
doing some work along these lines but I don't know what the status is.

Ian

Re: Edit-and-continue

[Dave Korn]

On 18/07/2010 16:28, Robert Dewar wrote:
> 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.
> 
> Unlikely to be feasible in my view without slowing down compilation
> substantially.

  I think you're probably assuming too much.  Tom T. is working on an
incremental compiler, isn't he?  I expect that that and LTO between them would
/ could give us all the tools we needed to make an EAC-friendly compiler.

  But yes, OP, it's a long-term project.

    cheers,
      DaveK

Re: [Bulk] Re: Edit-and-continue

[Terrence Miller]

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:
>    
>> 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.
>>>        
>> Unlikely to be feasible in my view without slowing down compilation
>> substantially.
>>      
>    I think you're probably assuming too much.  Tom T. is working on an
> incremental compiler, isn't he?  I expect that that and LTO between them would
> / could give us all the tools we needed to make an EAC-friendly compiler.
>
>    But yes, OP, it's a long-term project.
>
>      cheers,
>        DaveK
>
>
>
>    

Re: [Bulk] Re: Edit-and-continue

[Rick C. Hodgin]

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 are recompiled with a single change which affects it.  And if
there are shared resources loaded, each of those would have to be
updated as well, that is if we wanted to go "whole hog" like that.
Otherwise, we could limit the changes to only the currently-executing
program.

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 points for the executable code.
It would be slower for execution, but for development the time savings
would be there because changes could be made on the fly, recompiled,
memory variables changed as needed, and then continue execution without
restarting the entire app.

The ability would also have to be created to allow local variable
re-mapping across these updates, so that if the stack changed, the data
on the stack is migrated from its old locations to the new ones.  This
would be a table built by gcc that's passed to gdb for each function,
where gdb updates the stack in that way.  If parent functions on the
call stack were updated, they would have to be altered on the stack as
well.  This could be accommodated by automatically including a specified
amount of "extra space" in local variable space per function entry
point, something like 32 bytes (eight 4-byte variables) by default, with
a compiler switch to increase that block size.  This extra space would
allow for a certain number of new variables before a full recompile is
required again.  We could also have #pragma-like statements for
individual functions where we know some heavy changes will be used, to
give them an extra 512 bytes, or whatever's specified.

- Rick C. Hodgin

On Sun, 2010-07-18 at 12:36 -0700, Terrence Miller wrote:
> 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:
> >    
> >> 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.
> >>>        
> >> Unlikely to be feasible in my view without slowing down compilation
> >> substantially.
> >>      
> >    I think you're probably assuming too much.  Tom T. is working on an
> > incremental compiler, isn't he?  I expect that that and LTO between them would
> > / could give us all the tools we needed to make an EAC-friendly compiler.
> >
> >    But yes, OP, it's a long-term project.
> >
> >      cheers,
> >        DaveK
> >
> >
> >
> >    

Re: Edit-and-continue

[Rick C. Hodgin]

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

Re: [Bulk] Re: Edit-and-continue

[Jonathan Wakely]

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 points for the executable code.
> It would be slower for execution, but for development the time savings
> would be there because changes could be made on the fly, recompiled,
> memory variables changed as needed, and then continue execution without
> restarting the entire app.

I run the compiler a lot more than I run the debugger, so I'm not
entirely sold on the idea of development time savings, but I haven't
used Edit-and-Continue so I can't say how useful it is.

Re: [Bulk] Re: Edit-and-continue

[Rick C. Hodgin]

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 little mistakes like:

for (i=0; i<some_var; ++i)

which should've been:
for (i=0; i<(some_var-1); ++i)

can be changed on the fly.  Those simple, tiny little mistakes that are
prevalent, save so much time by going "OH MAN!" smacking your forehead,
changing it quickly, and pressing the key combo to apply changes.

It all takes 3 seconds, and you're continuing at the point in your
program where you were.

In addition, you can continue writing new code while running your app.
You write the new function, call it from some other place, set a
breakpoint, and then continue writing more code.

It's also awesome to examine the value of registers, memory variables,
then change the code quickly, apply changes, re-position the instruction
pointer, process through again, etc.

I'm amazed this hasn't already been introduced into GCC and G++.  If I
had the time to put into it, I would do it because I think this and the
commensurate abilities in GDB which would be required would move so many
developers over from Microsoft's toolsets.  Edit-and-continue is that
powerful.

- Rick C. Hodgin

On Sun, 2010-07-18 at 22:32 +0100, Jonathan Wakely wrote:
> 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 points for the executable code.
> > It would be slower for execution, but for development the time savings
> > would be there because changes could be made on the fly, recompiled,
> > memory variables changed as needed, and then continue execution without
> > restarting the entire app.
> 
> I run the compiler a lot more than I run the debugger, so I'm not
> entirely sold on the idea of development time savings, but I haven't
> used Edit-and-Continue so I can't say how useful it is.

Re: [Bulk] Re: Edit-and-continue

[Jonathan Wakely]

On 18 July 2010 23:15, Rick C. Hodgin <foxmuldrster@yahoo.com> 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 useful it is.  It's
> pretty darned amazing actually.  Once you use it, you'll always miss it.
> Simple little mistakes like:
>
> for (i=0; i<some_var; ++i)
>
> which should've been:
> for (i=0; i<(some_var-1); ++i)
>
> can be changed on the fly.  Those simple, tiny little mistakes that are
> prevalent, save so much time by going "OH MAN!" smacking your forehead,
> changing it quickly, and pressing the key combo to apply changes.
>
> It all takes 3 seconds, and you're continuing at the point in your
> program where you were.

Maybe we work on different kinds of program, but if I find the bug I'm
looking for I don't usually stay in the debugger.  The usefulness of
this feature isn't really relevant on this list though, if it's useful
to others then it doesn't matter much if I want to use it.

Re: [Bulk] Re: [Bulk] Re: Edit-and-continue

[Terrence Miller]

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 entry-point code of the old function with a branch 
to the new version.

On 7/18/2010 12:52 PM, Rick C. Hodgin wrote:
> 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 are recompiled with a single change which affects it.  And if
> there are shared resources loaded, each of those would have to be
> updated as well, that is if we wanted to go "whole hog" like that.
> Otherwise, we could limit the changes to only the currently-executing
> program.
>
> 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 points for the executable code.
> It would be slower for execution, but for development the time savings
> would be there because changes could be made on the fly, recompiled,
> memory variables changed as needed, and then continue execution without
> restarting the entire app.
>
> The ability would also have to be created to allow local variable
> re-mapping across these updates, so that if the stack changed, the data
> on the stack is migrated from its old locations to the new ones.  This
> would be a table built by gcc that's passed to gdb for each function,
> where gdb updates the stack in that way.  If parent functions on the
> call stack were updated, they would have to be altered on the stack as
> well.  This could be accommodated by automatically including a specified
> amount of "extra space" in local variable space per function entry
> point, something like 32 bytes (eight 4-byte variables) by default, with
> a compiler switch to increase that block size.  This extra space would
> allow for a certain number of new variables before a full recompile is
> required again.  We could also have #pragma-like statements for
> individual functions where we know some heavy changes will be used, to
> give them an extra 512 bytes, or whatever's specified.
>
> - Rick C. Hodgin
>
> On Sun, 2010-07-18 at 12:36 -0700, Terrence Miller wrote:
>    
>> 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:
>>>
>>>        
>>>> 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.
>>>>>
>>>>>            
>>>> Unlikely to be feasible in my view without slowing down compilation
>>>> substantially.
>>>>
>>>>          
>>>     I think you're probably assuming too much.  Tom T. is working on an
>>> incremental compiler, isn't he?  I expect that that and LTO between them would
>>> / could give us all the tools we needed to make an EAC-friendly compiler.
>>>
>>>     But yes, OP, it's a long-term project.
>>>
>>>       cheers,
>>>         DaveK
>>>
>>>
>>>
>>>
>>>        
>
>
>    

Re: Edit-and-continue

[Diego Novillo]

On Sun, Jul 18, 2010 at 14:37, Ian Lance Taylor <iant@google.com> wrote:

> This idea is related to Tom Tromey's incremental compiler work
> (http://gcc.gnu.org/wiki/IncrementalCompiler) and to Per Bothner's
> compiler server work
> (http://per.bothner.com/papers/GccSummit03-slides/index.html).  Neither
> project is currently active.  I believe that Diego Novillo is currently
> doing some work along these lines but I don't know what the status is.

We are finishing up a prototype implementation for per-file
pre-tokenization.  If this works out, we will see about adding parsing
results to the cache.  Our goal would be to finish Tom's incremental
compiler.  But we are still very much in preliminary stages of the
work.


Diego.

Re: Edit-and-continue

[Tom Tromey]

>>>>> "Dave" == Dave Korn <dave.korn.cygwin@gmail.com> writes:

Dave> I think you're probably assuming too much.  Tom T. is working on an
Dave> incremental compiler, isn't he?

I was, but I was asked to work on gdb a couple of years ago, so that
work is suspended.

Dave>   But yes, OP, it's a long-term project.

Apple implemented fix-and-continue in their toolchain.  They spoke about
it a little bit on the gdb list, it is in the archives.  My take-away
was that the feature is a lot of work for not much benefit, but YMMV,
and of course we'd be happy to review any gdb patches in this direction
:-)

Tom

Re: Edit-and-continue

[Chris Lattner]

On Jul 19, 2010, at 1:57 PM, Tom Tromey wrote:

> Dave>   But yes, OP, it's a long-term project.
> 
> Apple implemented fix-and-continue in their toolchain.  They spoke about
> it a little bit on the gdb list, it is in the archives.  My take-away
> was that the feature is a lot of work for not much benefit, but YMMV,
> and of course we'd be happy to review any gdb patches in this direction
> :-)

The use case for fix-and-continue is for long lived apps.  This has little to do with actual build times, it is useful when restarting the app and getting it back into the state to repro the problem takes a long time.

It is a useful feature and Apple did implement it in their toolchain, but it's worth noting that they've ripped it out since then.  Their specific implementation was too fragile to work consistently.

-Chris