From: Hui Zhu <teawater@gmail.com>
To: Marc Khouzam <marc.khouzam@ericsson.com>
Cc: "tromey@redhat.com" <tromey@redhat.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
Michael Snyder <msnyder@vmware.com>
Subject: Re: set record query <on|off>
Date: Mon, 14 Sep 2009 05:45:00 -0000 [thread overview]
Message-ID: <daef60380909132245u25a49249lcd6ff7e0bf8d6f13@mail.gmail.com> (raw)
In-Reply-To: <F7CE05678329534C957159168FA70DEC5153600717@EUSAACMS0703.eamcs.ericsson.se>
On Mon, Sep 14, 2009 at 08:21, Marc Khouzam <marc.khouzam@ericsson.com> wrote:
>
>> -----Original Message-----
>> From: Hui Zhu [mailto:teawater@gmail.com]
>> Sent: September-11-09 10:57 PM
>> To: Marc Khouzam
>> Cc: tromey@redhat.com; gdb-patches@sourceware.org; Michael Snyder
>> Subject: Re: set record query <on|off>
>>
>> If you don't mind. I suggest you discussion "Eclipse handle query" in
>> a special thread.
>
> You are probably right that it may be a good way to proceed.
> I'll try to come up with an other suggest and start a new thread also.
>
>> 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?
>
> I see your point and it may be useful to some people.
> On the other hand it may be going a bit far in giving the user
> different configuration options.
>
> In any case, if this approach is the one chosen, it would solve
> my problem, so I'm not against it :-) but I would lean towards
> something simpler. But that is just me.
>
> Thanks
>
> Marc
>
>
>>
>>
>> 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
>> >
>>
Hi Marc,
If you really cannot handle query with Eclipse, I think this patch is
OK with me. Because I really want prec in 7.0 can work well with
Eclipse. I will add switch for each query.
BTW, I suggest don't add "set record query <on|off>" to doc. Because
I don't want simple customer use it because we have switch for each
query.
Thanks,
Hui
next prev parent reply other threads:[~2009-09-14 5:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-11 15:04 Marc Khouzam
2009-09-11 22:07 ` Tom Tromey
2009-09-12 1:08 ` Marc Khouzam
2009-09-12 2:57 ` Hui Zhu
2009-09-14 0:23 ` Marc Khouzam
2009-09-14 5:45 ` Hui Zhu [this message]
2009-09-14 13:54 ` Marc Khouzam
2009-09-14 16:24 ` Hui Zhu
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=daef60380909132245u25a49249lcd6ff7e0bf8d6f13@mail.gmail.com \
--to=teawater@gmail.com \
--cc=gdb-patches@sourceware.org \
--cc=marc.khouzam@ericsson.com \
--cc=msnyder@vmware.com \
--cc=tromey@redhat.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