This is the mail archive of the gdb@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: [RFC] Queries and frontends


On Tue, Jul 21, 2009 at 16:26, Hui Zhu<teawater@gmail.com> wrote:
> On Tue, Jul 21, 2009 at 14:13, Nick Roberts<nickrob@snap.net.nz> wrote:
>> ?> First, let's mention the "set confirm off" command. ?The documentation
>> ?> at section 20.7 reads:
>> ?> "If you are willing to unflinchingly face the consequences of your own
>> ?> commands, you can disable this "feature":"
>> ?>
>> ?> So, from the doc and from what seems (to me :-)) like the proper
>> ?> behavior, when we "set confirm off", all commands that use a query
>> ?> should simply be performed without asking the user.
>> ?>
>> ?> The current implementation of queries does not do that. ?Instead,
>> ?> it will follow the default answer of a query. ?Such a default answer
>> ?> makes sense when trying to guide the user in a choice, but when
>> ?> "set confirm off" we should really let the command execute.
>>
>> The behaviour is as I would expect from the documentation.
>>
>> ?> As an example, setting pending breakpoints has a default answer of 'n'.
>> ?> What that means (unless I'm wrong) is that with "set confirm off",
>> ?> pending breakpoints will NOT be set.
>> ?>
>> ?> The patch below changes defaulted_query() to always answer "yes" if
>> ?> 'confirm' is off.
>>
>> I would find this behaviour confusing. ?In any case, the "set confirm off"
>> command is for interactive use, not front ends.
>>
>> Here's a revised patch for my original request. ?It doesn't help with issues
>> relating to GDB/MI but just uses the "server prefix" instead of a special
>> option. ?I have used this trick previously (2007-07-10) to avoid setting the
>> convenience variable $_ with breakpoints. ?This seems appropriate as I think
>> the "server" command was created many years ago by Tom Lord or Jim Kingdon for
>> use with annotations. ?I could add a suitable note to the documentation.
>>
>> --
>> Nick ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? http://www.inet.net.nz/~nickrob
>>
>>
>> 2009-07-21 ?Nick Roberts ?<nickrob@snap.net.nz>
>>
>> ? ? ? ?* record.c (cmd_record_stop): Don't ask for confirmation if
>> ? ? ? ?server prefix is used.
>>
>>
>> *** record.c.~1.8.~ ? ? 2009-07-21 17:58:01.000000000 +1200
>> --- record.c ? ?2009-07-21 18:02:30.000000000 +1200
>> ***************
>> *** 24,29 ****
>> --- 24,30 ----
>> ?#include "event-top.h"
>> ?#include "exceptions.h"
>> ?#include "record.h"
>> + #include "top.h"
>>
>> ?#include <signal.h>
>>
>> *************** cmd_record_stop (char *args, int from_tt
>> *** 1157,1164 ****
>> ?{
>> ? ?if (current_target.to_stratum == record_stratum)
>> ? ? ?{
>> ! ? ? ? if (!record_list || !from_tty || query (_("Delete recorded log and "
>> ! ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "stop recording?")))
>> ? ? ? ?unpush_target (&record_ops);
>> ? ? ?}
>> ? ?else
>> --- 1158,1165 ----
>> ?{
>> ? ?if (current_target.to_stratum == record_stratum)
>> ? ? ?{
>> ! ? ? ? if (!record_list || !from_tty || server_command
>> ! ? ? ? ? || query (_("Delete recorded log and stop recording?")))
>> ? ? ? ?unpush_target (&record_ops);
>> ? ? ?}
>> ? ?else
>>
>
> About this patch. ?I had said that I think add a special command for
> it is better.
>
BTW,  what about this?

maintenance print target-stack
The current target stack is:
  - record (Process record and replay target)
  - child (Unix child process)
  - exec (Local exec file)
  - None (None)

Thanks,
Hui


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