RE: Another proposal for frontends and queries.

[Marc Khouzam <marc dot khouzam at ericsson dot com>]

> -----Original Message-----
> From: Joel Brobecker [mailto:brobecker@adacore.com] 
> Sent: Wednesday, September 16, 2009 10:26 AM
> To: Hui Zhu
> Cc: Marc Khouzam; Pedro Alves; gdb-patches@sourceware.org; 
> Michael Snyder
> Subject: Re: Another proposal for frontends and queries.
> 
> > And about the patch I said can handle this issue is "set 
> record query
> > <on|off>" patch.  I cannot find who don't like this patch.
> 
> I am one of the maintainers would dislike this idea.
> 
> > On the other hand, about the nquery.
> > Let me talk my idea.  The nquery is a function of GDB 
> right?  MI is a
> > function of GDB too.   Eclipse is a very important soft that support
> > GDB.
> > If you want change nquery to query, why not remove nquery directly?
> 
> I had the same thoughts, actually. But we have one more usage of that
> function relative to pending breakpoints, and for some reason it was
> decided that the default was 'n' rather than 'y'. Not sure why.

The whole nquery/yquery was introduced because of pending breakpoints.
If I understand the emails properly (http://sourceware.org/ml/gdb/2004-02/msg00108.html)
the new pending breakpoint feature broke the test scripts because
breakpoints that failed to install would now be made pending.
The nquery was meant to have the test scripts avoid that change.

I wonder if the flag "set breakpoint pending" was added after that.
Using this flag probably would have been good enough to avoid the 
whole nquery.
Maybe that is a solution we can take?  Remove nquery/yquery and
use "set breakpoint pending" for the pending breakpoints in test scripts?


> 
> I'm also thinking that what we need is an enhancement of the 
> MI protocol
> to handle queries that the frontends can then pass to the user for
> answering.  But this is just a wild idea at this point, as I 
> don't know
> the MI protocol much. Plus, it would probably be a fairly significant
> update unsuitable for 7.0.
> 
> -- 
> Joel
>