Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: gdb-patches@sources.redhat.com
Subject: Re: RFA: Breakpoint infrastructure cleanups [0/8]
Date: Thu, 16 Oct 2003 13:11:00 -0000	[thread overview]
Message-ID: <20031016131144.GA14202@nevyn.them.org> (raw)
In-Reply-To: <2719-Thu16Oct2003085405+0200-eliz@elta.co.il>

On Thu, Oct 16, 2003 at 08:54:05AM +0200, Eli Zaretskii wrote:
> > From: Elena Zannoni <ezannoni@redhat.com>
> > Date: Wed, 15 Oct 2003 15:07:41 -0400
> > 
> > 1. insert the breakpoint, show confirmation to the user. If we have 20
> >    'real' breakpoints inserted, what do we tell the user? 
> 
> If we can guess the one address which is what the user wants to see in
> the current context, let's show that single address.  Otherwise, let's
> either show all of them or none at all, perhaps controlled by some
> user option.

Seems reasonable.

> > 2. hit the breakpoint, show line info about where we stopped, and
> >    breakpoint number. Do we just say the program hit the high level
> >    breakpoint number, or also which low level breakpoint number?
> 
> I'd say we show the high-level number and the precise machine address
> where it breaks.

Right now we show the breakpoint address for breakpoints which are not
at the beginning of a source line, and just the breakpoint and line
numbers for breakpoints which are at the beginning of a line.  How
would this interact with that?  Show the address always, or for
breakpoints which either are in the middle of a line or in multiple
locations?

> >    Hmm, do low level breakpoints have numbers?
> 
> I don't think we need numbers for them, so let's not have them.

I actually think that we do need numbers for them.

My hypothetical use case is something like this:
(gdb) break inline_foo
Breakpoint 5 set at inline_foo, which has multiple locations.
Say "info breakpoint 5" for more details.
(gdb) info break 5
Num Type          Enb Address    What
1   sw breakpoint  y  0x8040222  inlined into foo
2   sw breakpoint  y  0x8040822  inlined into bar
3   sw breakpoint  y  0x8040852  inlined into boring_loop
(gdb) disable 5.3
(gdb) run

I am not sure about "delete 5.3", though - that makes tracking which
breakpoints have been set a little trickier, for not much gain.

> > And MI? what should we do there? the same 3 cases occur.  I would
> > think that MI could just tell the gui everything every time, and then
> > the GUI could decide to display what it wants.
> 
> Probably.
> 
> > However that's a lot
> > of information sent back and forth, maybe for no real advantage. So
> > maybe a two-tier command set is needed there too.
> 
> Yes, probably.

These make sense to me also.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


  reply	other threads:[~2003-10-16 13:11 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-08 16:55 Daniel Jacobowitz
2003-10-08 17:33 ` Elena Zannoni
2003-10-08 19:04   ` Andrew Cagney
2003-10-08 19:07     ` Daniel Jacobowitz
2003-10-08 19:44       ` David Carlton
2003-10-08 20:36         ` Elena Zannoni
2003-10-08 19:49       ` Andrew Cagney
2003-10-08 18:07 ` Jim Blandy
2003-10-08 18:23   ` Joel Brobecker
2003-10-08 19:05   ` Daniel Jacobowitz
2003-10-08 19:52     ` Andrew Cagney
2003-10-08 20:30       ` Daniel Jacobowitz
2003-10-08 21:09         ` Andrew Cagney
2003-10-08 21:11           ` Daniel Jacobowitz
2003-10-08 21:40             ` Elena Zannoni
2003-10-08 22:28             ` Andrew Cagney
2003-10-09 19:19       ` Michael Snyder
2003-10-14  1:38         ` Daniel Jacobowitz
2003-10-14 15:40           ` Andrew Cagney
2003-10-14 15:46             ` David Carlton
2003-10-14 15:51             ` Daniel Jacobowitz
2003-10-14 16:27               ` Elena Zannoni
2003-10-14 20:45               ` Michael Snyder
2003-10-15 15:02                 ` Andrew Cagney
2003-10-15 18:20                   ` Michael Snyder
2003-10-15 18:30                     ` Andrew Cagney
2003-10-15 22:19                       ` Michael Snyder
2003-10-15 22:23                         ` Andrew Cagney
2003-10-15 22:37                           ` Michael Snyder
2003-10-15 18:56                     ` Elena Zannoni
2003-10-16  6:59                       ` Eli Zaretskii
2003-10-16 13:11                         ` Daniel Jacobowitz [this message]
2003-10-16 14:08                           ` Paul Koning
2003-10-16 14:21                           ` Elena Zannoni
2003-10-16 15:54                             ` Eli Zaretskii
2003-10-16 23:20                               ` Michael Snyder
2003-10-16 23:18                             ` Michael Snyder
2003-10-16 15:45                           ` Eli Zaretskii
2003-10-16 23:14                           ` Michael Snyder
2003-10-15 22:41                 ` Daniel Jacobowitz
2003-10-16  6:55                   ` Eli Zaretskii
2003-10-16 14:25                     ` Andrew Cagney
2003-10-16 16:02                       ` Eli Zaretskii
2003-10-16 23:24                         ` Michael Snyder
2003-10-17  6:46                           ` Eli Zaretskii
2003-10-17 21:38                             ` Michael Snyder
2003-10-18  8:43                               ` Eli Zaretskii
2003-10-20 18:48                                 ` Michael Snyder
2003-10-16 16:16                       ` Daniel Jacobowitz
2003-10-16 18:20                         ` Andrew Cagney
2003-10-16 23:26                           ` Totally OT Michael Snyder
2003-10-16 16:03                   ` RFA: Breakpoint infrastructure cleanups [0/8] David Carlton
2003-10-16 16:17                     ` Daniel Jacobowitz
2003-10-08 20:55     ` Elena Zannoni
2003-10-08 20:59       ` Daniel Jacobowitz
2003-10-09  6:09     ` Eli Zaretskii
2003-10-09 14:08       ` Daniel Jacobowitz
2003-10-09 17:02         ` Eli Zaretskii
2003-10-09 19:41           ` Daniel Jacobowitz
2003-10-19 16:43           ` Andrew Cagney
2003-10-09 19:33         ` Michael Snyder
2003-10-08 19:38   ` David Carlton
2003-10-08 21:00     ` Daniel Jacobowitz
2003-10-09  6:07     ` Eli Zaretskii
2003-10-08 18:26 ` Eli Zaretskii
2003-10-08 19:09   ` Daniel Jacobowitz
2003-10-19 15:55 ` Andrew Cagney
2003-10-19 16:39   ` Eli Zaretskii
2003-10-30  5:49     ` Daniel Jacobowitz
2003-11-03 18:00       ` Daniel Jacobowitz
2003-11-04 19:57       ` Michael Snyder
     [not found] <1065728983.12011.ezmlm@sources.redhat.com>
2003-10-09 20:01 ` Jim Ingham
2003-10-15 19:48 Michael Elizabeth Chastain
2003-10-15 22:00 ` Michael Snyder
2003-10-15 22:14 Michael Elizabeth Chastain
2003-10-15 22:36 ` Michael Snyder
     [not found] <1066321046.18949.ezmlm@sources.redhat.com>
2003-10-16 18:58 ` Jim Ingham
2003-10-16 23:30   ` Michael Snyder
2003-10-16 19:02 ` Jim Ingham
2003-10-17  7:04   ` Eli Zaretskii
2003-10-17 16:55     ` Jim Ingham

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=20031016131144.GA14202@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.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