Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Nick Roberts <nickrob@snap.net.nz>
To: Jason Molenda <jmolenda@apple.com>,
		Joel Brobecker <brobecker@adacore.com>,
	gdb@sourceware.org
Subject: Re: GDB Focus Group at the 2008 GCC Summit
Date: Tue, 24 Jun 2008 21:18:00 -0000	[thread overview]
Message-ID: <18529.25738.895554.417986@kahikatea.snap.net.nz> (raw)
In-Reply-To: <18528.8720.477338.668458@kahikatea.snap.net.nz>

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.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


  reply	other threads:[~2008-06-24 21:18 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-19 19:10 Joel Brobecker
2008-06-22  6:08 ` Thiago Jung Bauermann
2008-06-22 11:52 ` Nick Roberts
2008-06-22 13:53   ` Joel Brobecker
2008-06-23 15:17   ` Tom Tromey
2008-06-23 17:35     ` Jim Ingham
2008-06-23 21:55     ` Nick Roberts
2008-06-23 15:16 ` Tom Tromey
2008-06-26  0:24   ` Tom Tromey
2008-07-03  3:27   ` Thiago Jung Bauermann
2008-07-03  8:12     ` Andreas Schwab
2008-07-03 12:35     ` Daniel Jacobowitz
2008-07-03 14:28       ` Thiago Jung Bauermann
2008-07-04  2:33       ` Tom Tromey
2008-07-04  3:19         ` Daniel Jacobowitz
2008-06-23 21:46 ` Jason Molenda
2008-06-23 22:22   ` Nick Roberts
2008-06-24 21:18     ` Nick Roberts [this message]
2008-06-25  6:56       ` [MI] changing breakpoint location (Was: GDB Focus Group at the 2008 GCC Summit) Vladimir Prus
2008-06-23 22:09 ` GDB Focus Group at the 2008 GCC Summit Mark Kettenis
2008-06-23 22:26   ` Joel Brobecker
2008-06-24  8:35   ` Andrew STUBBS
2008-06-24  8:56     ` Andreas Schwab
2008-06-24 18:12     ` Michael Snyder
2008-06-24 18:28     ` Daniel Jacobowitz
2008-06-24 19:33     ` Dave Korn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=18529.25738.895554.417986@kahikatea.snap.net.nz \
    --to=nickrob@snap.net.nz \
    --cc=brobecker@adacore.com \
    --cc=gdb@sourceware.org \
    --cc=jmolenda@apple.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox