Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Nick Roberts <nickrob@snap.net.nz>
To: Vladimir Prus <ghost@cs.msu.su>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] Re: bug in mi when setting breakpoint
Date: Mon, 21 Jan 2008 08:41:00 -0000	[thread overview]
Message-ID: <18324.23166.605304.400302@kahikatea.snap.net.nz> (raw)
In-Reply-To: <200801211028.07452.ghost@cs.msu.su>

 > We expect that basic non-stop mode will be available in about three months
 > from now.

OK, thanks.

 > > They wouldn't.  I don't see why we should design MI commands around a
 > > feature that doesn't exist yet and will presumably be optional.
 > 
 > As I've mentioned, in non-stop mode, adding all breakpoint and then removing
 > undesired ones won't work. So, we need MI support for adding only needed
 > breakpoints. And once we implement such support, and use it in non-stop
 > mode, it won't make much sense to use some different mechanism in all-stop
 > mode -- that will only complicate logic without much benefit.

If your timescale is realistic and your proposal practical then I agree.

 > > In Emacs, multiple breakpoints for overloaded functions would be specified
 > > from the GUD buffer.  How do you specify them graphically?
 > 
 > You present a list of overloaded function, with checkboxes next to each
 > name, that user would check and uncheck as he see fit.

You previously said:

   1. UI should not require to type GDB command for such basic task as adding
   breakpoints.

My point was that in the GUD buffer you can specify an overloaded function,
A::f, by typing

(gdb) break A::f

and get breakpoints in A::f(double), A::f(int), say, but if you click on a line
inside an overloaded function, generally you will only get one breakpoint.

 > > It all seems rather elaborate, but I don't feel that strongly about it as
 > > I'm not yet in a position to fully migrate Emacs to GDB/MI.
 > 
 > BTW, insert-all-and-remove-undesired would be as complex. First, you need to
 > detect that several breakpoints were inserted (-break-insert will return
 > several breakpoint ids in that case). Then, you better tell the user about
 > this fact, as he might not be looking at gdb console. And ideally, you'll
 > actually pop up a list of just inserted breakpoints and let the user delete
 > those he does not want -- which is just as complex for frontend as the
 > scheme I've suggested.

I can only see such breakpoints being set from the GUD buffer and the
current warning gets printed there.  He can look at the breakpoints buffer if
he wishes to know more.

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


  reply	other threads:[~2008-01-21  8:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20071216125625.GE4783@coin>
     [not found] ` <18277.36237.521792.245470@kahikatea.snap.net.nz>
     [not found]   ` <18316.10856.89097.335103@kahikatea.snap.net.nz>
2008-01-16 22:37     ` Nick Roberts
2008-01-17 14:26       ` Vladimir Prus
2008-01-17 20:35         ` Nick Roberts
2008-01-19 11:52           ` Vladimir Prus
2008-01-19 21:45             ` Nick Roberts
2008-01-20 10:08               ` Vladimir Prus
2008-01-20 10:38                 ` Nick Roberts
2008-01-20 11:09                   ` Vladimir Prus
2008-01-20 20:32                     ` Nick Roberts
2008-01-21  7:28                       ` Vladimir Prus
2008-01-21  8:41                         ` Nick Roberts [this message]
2008-01-29 20:15                         ` Daniel Jacobowitz

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=18324.23166.605304.400302@kahikatea.snap.net.nz \
    --to=nickrob@snap.net.nz \
    --cc=gdb-patches@sources.redhat.com \
    --cc=ghost@cs.msu.su \
    /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