Re: Another proposal for frontends and queries.

Joel Brobecker
2009-09-14T15:23:57Z

> > 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