GDB Focus Group at the 2008 GCC Summit

[Jim Ingham]

On Jun 24, 2008, at 2:18 PM, Nick Roberts wrote:

> Nick Roberts writes:
>>> The IDE is responsible for removing & reinserting breakpoints at the
>>> correct line numbers.  If you had a breakpoint on main.c:35 and you
>>> added a couple of lines of code earlier in the file, that breakpoint
>>> needs to be moved to main.c:37.
>>
>> Quite apart from fix and continue, it would be useful when GDB  
>> realises that
>> an executable has been recompiled and says:
>>
>>  `myprog' has changed; re-reading symbols.
>>
>> if it could also compute and print the new breakpoint locations,  
>> possibly
>> only in MI as an event notification ("=breakpoints-changed").
>
> I was thinking that GDB could detect that the location had changed  
> but maybe
> (as Jason suggests the IDE should do it (certainly if the edit  
> source in Emacs
> the breakpoint icon moves with it's associated line).  In which case  
> it would
> seem useful to have an MI command that could move an existing  
> breakpoint, e.g.,
>
>   -break-insert -m BPTNO FILE:LINE
>
> rather than delete the existing breakpoint and create a new one so  
> that the
> breakpoint number is preserved.  If the example above is breakpoint 4:
>
>   -break-insert -m 4 main.c:37
>
> Perhaps Apple GDB already does something like this.

gdb can't know where a given line has moved to.  You need the editor  
to track that.

Since Xcode supports persistent breakpoints, it already had all the  
machinery to reconstruct breakpoints in their entirety.  So we didn't  
add a move breakpoint command.  The only bit of consequence that  
doesn't follow the move is the hit count (and I guess Xcode could fake  
that up on its side if we really cared.)

The old NeXT version of gdb actually did have a move-breakpoint  
command, but nobody much used it, and it kept breaking when we did  
merges, so we removed it years ago.

Still, it would be a useful addition.

Jim