Re: set record query <on|off>

[Hui Zhu <teawater at gmail dot com>]

If you don't mind.  I suggest you discussion "Eclipse handle query" in
a special thread.

Let's talk about my idea about this patch.  I think give a switch to
close the query in the prec is not bad.  Even if we don't use Eclipse,
we still need close query sometime.
But someone want this swich always "yes", someone want always "no".

So I suggest each query have a special "switch" to control it.
For example:
set record query off
set record changememory yes
set record changereg yes

If query is on, this yes or no choice yquery or nquery.  If query is
off, this yes or no can be the answer.

What do you think about it?


Thanks,
Hui


On Sat, Sep 12, 2009 at 09:08, Marc Khouzam <marc.khouzam@ericsson.com> wrote:
>> -----Original Message-----
>> From: Tom Tromey [mailto:tromey@redhat.com]
>> Sent: September-11-09 6:07 PM
>> To: Marc Khouzam
>> Cc: 'gdb-patches@sourceware.org'
>> Subject: Re: set record query <on|off>
>>
>> >>>>> "Marc" == Marc Khouzam <marc.khouzam@ericsson.com> writes:
>>
>> Marc> here is a patch to allow to enable/disable the queries
>> Marc> used in Record. ?It is relevant to:
>> Marc> http://sourceware.org/ml/gdb/2009-09/msg00165.html
>> Marc> What do you think?
>>
>> It seems like a strange approach to me.
>
> I was hoping for something more generic for queries, but in the few
> email exchanges, things kept coming back to such a specific new
> Record command.
>
>> I don't think I know the whole background here. ?Is this to help users
>> who enter commands at a console? ?Or MI? ?Or CLI commands sent by
>> Eclipse, but not from a user console (that is, in response to some GUI
>> control)?
>
> Sorry, I should have summarized the issue in the mail. ?Here goes.
>
> When Eclipse is interacting with GDB, there is a single "channel of
> communication" which is used for everything (MI, CLI when no MI equivalent,
> and Eclipse console). ?This channel triggers the GDB code paths
> that are "!input_from_terminal_p ()" and this makes every query
> be automatically answered with the default answer.
>
> This was not a problem before because there was only a single
> use of nquery() and it was never triggered by Eclipse
> (it was for pending breakpoints).
> With PRecord though, there are new uses of nquery(), and these, from Eclipse,
> keep being answer 'N' automatically.
>
> Only one case is actually a problem right now:
> it is when changing memory (or registers) while replaying execution; in this
> case there is an nquery(), and since it is automatically answered, I just
> cannot set memory during an replay. ?Being able to change memory during
> replay is one of the cool features of PRecord, and that is why I'm trying
> really hard to get this to work for 7.0.
> BTW, to attempt to set memory, we use -var-assign so I cannot use the
> "server" prefix.
>
>> For MI, it seems like there should be arguments to the
>> internal function
>> and then the MI commands should disable querying that way.
>> That is, you
>> don't need a new user-visible setting for this.
>
> Disabling queries based on MI is something that was brought up.
> The idea was to have queries check if the interpreter was MI and in
> this case, answer 'Y' to any query.
> I like this because it is more future-proof.
> Is that what you are suggesting too?
>
>> For the CLI-commands-sent-by-Eclipse case, it seems like you could use
>> the "server" prefix.
>
> This may be useful for other cases, but in the current case (-var-assign)
> it does not work.
>
>> For the console case... it seems to me that queries are just
>> a necessary part of that.
>
> It would be nicer to have queries in this case but not only does it
> not work because we are in the case !input_from_terminal_p (), but having
> a query would block the "communication channel" waiting for user input,
> which would somewhat lock-up the Eclipse GUI.
>
> So, to summarize the summary, I need a way to get GDB to answer 'Y' for every
> query, even nquery(). ?And right now, the only time this is needed is for PRecord.
>
> Thanks for any more guidance.
>
> Marc
>