This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GDB Focus Group at the 2008 GCC Summit



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]