This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Another proposal for frontends and queries.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]