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: set record query <on|off>


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


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