To know the stopped reason from hook-stop

To know the stopped reason from hook-stop

[Masatake YAMATO]

(I am very new to this list.
 If my topic is suitable to this list, tell me the better list.)

Is there way to know in hook-stop the reason why the execution 
is stopped?

I could not find the way to do it, so I've just written a patch.
The patch is far from complete, but I'd like to know how to improve
it and integrate it to gdb official source tree. So I post the patch 
here.


The reason is passed through with $arg. 
$arg0 is the number which represents the reason; $arg0 holds the
number defined in gdb/target.h::target_waitkind. When I started working
on this patch, I'd like to pass the reason in a string. However, I 
found that a string could not be used if the debuggee process was gone.
So currently I'm using a number to represent the reason. With my patch
you can do like this in your .gdbinit:

    define hook-stop
           # show stack trace only when the debuggee is 
           # received a signal.
	   if $arg0 == 1
	      where
	   else
	      quit
	   end
    end

Regards,
Masatake YAMATO

Index: gdb/command.h
===================================================================
RCS file: /cvs/src/src/gdb/command.h,v
retrieving revision 1.56
diff -u -r1.56 command.h
--- gdb/command.h	9 Jan 2007 17:58:50 -0000	1.56
+++ gdb/command.h	31 Jul 2007 13:14:33 -0000
@@ -152,6 +152,7 @@
 /* Execute CMD's pre/post hook.  Throw an error if the command fails.
    If already executing this pre/post hook, or there is no pre/post
    hook, the call is silently ignored.  */
+extern void execute_cmd_pre_hook_with_arg (struct cmd_list_element *cmd, char *arg);
 extern void execute_cmd_pre_hook (struct cmd_list_element *cmd);
 extern void execute_cmd_post_hook (struct cmd_list_element *cmd);
 
Index: gdb/infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.244
diff -u -r1.244 infrun.c
--- gdb/infrun.c	2 Jul 2007 21:29:27 -0000	1.244
+++ gdb/infrun.c	31 Jul 2007 13:14:34 -0000
@@ -3286,7 +3286,53 @@
 static int
 hook_stop_stub (void *cmd)
 {
-  execute_cmd_pre_hook ((struct cmd_list_element *) cmd);
+  char args_buffer[128];
+  struct target_waitstatus last;
+  ptid_t last_ptid;
+
+  get_last_target_status (&last_ptid, &last);
+
+
+  args_buffer[0] = '\0';
+  switch (last.kind)
+    {
+    case TARGET_WAITKIND_EXITED:
+      sprintf(args_buffer, "%d %s %d", last.kind, "exited", last.value.integer);
+      break;
+    case TARGET_WAITKIND_STOPPED:
+      sprintf(args_buffer, "%d %s %d", last.kind, "stopped", last.value.sig);
+      break;
+    case TARGET_WAITKIND_SIGNALLED:
+      sprintf(args_buffer, "%d %s %d", last.kind, "signalled", last.value.sig);
+      break;
+    case TARGET_WAITKIND_LOADED:
+      sprintf(args_buffer, "%d %s", last.kind, "loaded");
+      break;
+    case TARGET_WAITKIND_FORKED:
+      sprintf(args_buffer, "%d %s %u", last.kind, "forked", last.value.related_pid);
+      break;
+    case TARGET_WAITKIND_VFORKED:
+      sprintf(args_buffer, "%d %s %u", last.kind, "vforked", last.value.related_pid);
+      break;
+    case TARGET_WAITKIND_EXECD:
+      // sprintf(args_buffer, "%s %s", "execd", value.execd_pathname);
+      break;
+    case TARGET_WAITKIND_SYSCALL_ENTRY:
+      sprintf(args_buffer, "%d %s %u", last.kind, "syscall_entry", last.value.syscall_id);
+      break;
+    case TARGET_WAITKIND_SYSCALL_RETURN:
+      sprintf(args_buffer, "%d %s %u", last.kind, "syscall_return", last.value.syscall_id);
+      break;
+    case TARGET_WAITKIND_SPURIOUS:
+      sprintf(args_buffer, "%d %s", last.kind, "spurious");
+      break;
+    case TARGET_WAITKIND_IGNORE:
+      sprintf(args_buffer, "%d %s", last.kind, "ignore");
+      break;
+    }
+  
+  execute_cmd_pre_hook_with_arg ((struct cmd_list_element *) cmd,
+				 args_buffer);
   return (0);
 }
 \f
cvs diff: Diffing gdb/cli
Index: gdb/cli/cli-script.c
===================================================================
RCS file: /cvs/src/src/gdb/cli/cli-script.c,v
retrieving revision 1.42
diff -u -r1.42 cli-script.c
--- gdb/cli/cli-script.c	3 Jul 2007 01:23:01 -0000	1.42
+++ gdb/cli/cli-script.c	31 Jul 2007 13:14:34 -0000
@@ -242,18 +242,24 @@
 }
 
 void
-execute_cmd_pre_hook (struct cmd_list_element *c)
+execute_cmd_pre_hook_with_arg (struct cmd_list_element *c, char *arg)
 {
   if ((c->hook_pre) && (!c->hook_in))
     {
       struct cleanup *cleanups = make_cleanup (clear_hook_in_cleanup, c);
       c->hook_in = 1; /* Prevent recursive hooking */
-      execute_user_command (c->hook_pre, (char *) 0);
+      execute_user_command (c->hook_pre, arg);
       do_cleanups (cleanups);
     }
 }
 
 void
+execute_cmd_pre_hook (struct cmd_list_element *c)
+{
+  execute_cmd_pre_hook_with_arg(c, (char *)0);
+}
+
+void
 execute_cmd_post_hook (struct cmd_list_element *c)
 {
   if ((c->hook_post) && (!c->hook_in))

Re: To know the stopped reason from hook-stop

[Jim Blandy]

Masatake YAMATO <yamato@redhat.com> writes:
> (I am very new to this list.
>  If my topic is suitable to this list, tell me the better list.)

This list is fine, since you were posting a patch.  Given that you're
also asking broad questions about GDB's design, gdb@ would have been
okay, too.

> Is there way to know in hook-stop the reason why the execution 
> is stopped?

No. :(

> I could not find the way to do it, so I've just written a patch.
> The patch is far from complete, but I'd like to know how to improve
> it and integrate it to gdb official source tree. So I post the patch 
> here.

Hmm.

It's painful to watch people wrestle GDB's scripting language into
doing something useful.  If Daniel's patch to add Python as a
scripting language for GDB were in the public sources, then I could
say, "Don't worry about trying to fix GDB's horrible scripting
language, provide this data to Python."  I'm sure that's the better
investment.

At the same time, I don't want to make the mistake of saying, "Oh, no,
let's not commit that improvement, something much better is coming
along real soon now" when there are no specific plans for the much
better thing's arrival.

Daniel, have you had time to work on that patch since we last talked
about it?

Re: To know the stopped reason from hook-stop

[Daniel Jacobowitz]

On Tue, Jul 31, 2007 at 12:18:05PM -0700, Jim Blandy wrote:
> It's painful to watch people wrestle GDB's scripting language into
> doing something useful.  If Daniel's patch to add Python as a
> scripting language for GDB were in the public sources, then I could
> say, "Don't worry about trying to fix GDB's horrible scripting
> language, provide this data to Python."  I'm sure that's the better
> investment.
> 
> At the same time, I don't want to make the mistake of saying, "Oh, no,
> let's not commit that improvement, something much better is coming
> along real soon now" when there are no specific plans for the much
> better thing's arrival.
> 
> Daniel, have you had time to work on that patch since we last talked
> about it?

I just started work on it again Sunday.  I'll try to make some more
time for it soon.

I'm afraid I really don't like this patch.  Adding magic numbers is
the only reasonable thing we can do in the existing CLI, but it is
arcane and hard to work with.  Once there's a better language in
place, we can be a lot more flexible.

(My scripting tree also has some patches to make using strings for
this sort of thing easier.)

-- 
Daniel Jacobowitz
CodeSourcery

Re: To know the stopped reason from hook-stop

[Masatake YAMATO]

> > It's painful to watch people wrestle GDB's scripting language into
> > doing something useful.  If Daniel's patch to add Python as a
> > scripting language for GDB were in the public sources, then I could
> > say, "Don't worry about trying to fix GDB's horrible scripting
> > language, provide this data to Python."  I'm sure that's the better
> > investment.
> > 
> > At the same time, I don't want to make the mistake of saying, "Oh, no,
> > let's not commit that improvement, something much better is coming
> > along real soon now" when there are no specific plans for the much
> > better thing's arrival.
> > 
> > Daniel, have you had time to work on that patch since we last talked
> > about it?
> 
> I just started work on it again Sunday.  I'll try to make some more
> time for it soon.
> 
> I'm afraid I really don't like this patch.  Adding magic numbers is
> the only reasonable thing we can do in the existing CLI, but it is
> arcane and hard to work with.  Once there's a better language in
> place, we can be a lot more flexible.

I agree with you.

> (My scripting tree also has some patches to make using strings for
> this sort of thing easier.)

Great.

Masatake YAMATO