From: Joel Brobecker <brobecker@adacore.com>
To: Marc Khouzam <marc.khouzam@ericsson.com>
Cc: "'gdb-patches@sourceware.org'" <gdb-patches@sourceware.org>
Subject: Re: Another proposal for frontends and queries.
Date: Mon, 14 Sep 2009 15:23:00 -0000 [thread overview]
Message-ID: <20090914152341.GG8327@adacore.com> (raw)
In-Reply-To: <F7CE05678329534C957159168FA70DEC515360090D@EUSAACMS0703.eamcs.ericsson.se>
> > The only issue, really, is how to detect that situation from the FE
> > so that it can itself ask the user for confirmation before it sends
> > the command...
>
> If a FE wants to ask the user directly, it can do that no matter
> what GDB will do. So I don't think there is a problem here. But
> maybe I misundertood your point?
Another way to look at what I was trying to say is to compare the
situation between GDB/CLI and GDB/MI:
1. In the first case, if you do:
(gdb) print a = 2
You should get a query from the debugger informing you that you
are about to change some memory and therefore lose the record log.
Are you sure?
2. In the second case, assuming that the query gets auto-answered
to 'y', you will not see the query, and you will lose your record
log without having a chance to abort the operation. In this regard,
the CLI interface is better (IMO).
Usually, I would guess that FEs do sanity checks, asking users
confirmation before sending an operation that could have unwanted
consequences. For instance, before sending the "quit" command,
they ask the user to confirm that they want to quit.
In this particular case, however, it's not clear how to perform
any sanity check at the FE level. Nor does it seem desirable, as
it would duplicate in the FE some of the logic we already have
in GDB.
There is also what you said:
> Having a switch on a command turns out to be insufficient because
> there is not a 1-1 mapping between queries and commands. Currently
> PRecord will query before changing memory, but this will be triggered
> by any of:
> -var-assign a 8
> p a=8
> set var a=8
After having written all this, it seems to me that I am suggesting
a level of complexity that is unnecessary, at least for now. Changing
the nquery to a query seems like the right thing to do, and would
render all these considerations OBE.
--
Joel
next prev parent reply other threads:[~2009-09-14 15:23 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-14 2:38 Marc Khouzam
2009-09-14 6:45 ` Vladimir Prus
2009-09-14 13:07 ` Marc Khouzam
2009-09-14 14:09 ` Joel Brobecker
2009-09-14 14:28 ` Marc Khouzam
2009-09-14 14:48 ` Pedro Alves
2009-09-14 14:57 ` Marc Khouzam
2009-09-14 15:08 ` Joel Brobecker
2009-09-14 15:36 ` Marc Khouzam
2009-09-14 16:06 ` Joel Brobecker
2009-09-15 16:26 ` Joel Brobecker
2009-09-16 6:24 ` Hui Zhu
2009-09-16 12:38 ` Marc Khouzam
2009-09-16 13:06 ` Hui Zhu
2009-09-16 13:25 ` Pedro Alves
2009-09-16 13:46 ` Hui Zhu
2009-09-16 13:59 ` Marc Khouzam
2009-09-16 14:17 ` Hui Zhu
2009-09-16 14:26 ` Joel Brobecker
2009-09-16 14:34 ` Hui Zhu
2009-09-16 14:45 ` Pedro Alves
2009-09-16 14:43 ` Marc Khouzam
2009-09-16 18:03 ` Tom Tromey
2009-09-16 23:36 ` Hui Zhu
2009-09-16 23:40 ` Joel Brobecker
2009-09-16 17:12 ` Eli Zaretskii
2009-09-14 15:23 ` Joel Brobecker [this message]
2009-09-16 20:20 ` Tom Tromey
2009-09-16 20:35 ` Marc Khouzam
2009-09-17 0:17 ` Michael Snyder
2009-09-17 0:48 ` Marc Khouzam
2009-09-17 1:03 ` Joel Brobecker
2009-09-17 2:07 ` Marc Khouzam
2009-09-17 0:16 ` Michael Snyder
2009-09-16 20:43 ` Tom Tromey
2009-09-16 21:41 ` Joel Brobecker
2009-09-17 13:51 ` Marc Khouzam
2009-09-17 19:52 ` Tom Tromey
2009-09-18 4:59 ` Hui Zhu
2009-09-18 5:16 ` Michael Snyder
2009-09-18 9:31 ` Pedro Alves
2009-09-18 14:37 ` Joel Brobecker
2009-09-18 14:57 ` Marc Khouzam
2009-09-18 16:42 ` Tom Tromey
2009-09-22 0:46 ` Marc Khouzam
2009-09-22 22:49 ` [RFA/commit] s/nquery/query/ in record.c (was "Re: Another proposal for frontends and queries.") Joel Brobecker
2009-09-23 12:45 ` Marc Khouzam
2009-09-24 3:05 ` Hui Zhu
2009-09-24 17:59 ` Joel Brobecker
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=20090914152341.GG8327@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=marc.khouzam@ericsson.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