Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "J. Johnston" <jjohnstn@redhat.com>
To: Andrew Cagney <ac131313@redhat.com>
Cc: Daniel Jacobowitz <drow@mvista.com>, gdb-patches@sources.redhat.com
Subject: Re: RFC: fix problems with errors during quitting (killed.exp)
Date: Thu, 11 Sep 2003 20:11:00 -0000	[thread overview]
Message-ID: <3F60D701.8060200@redhat.com> (raw)
In-Reply-To: <3F5F6F2C.2030403@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2622 bytes --]



Andrew Cagney wrote:
>>> My new strategy is to intercept error() calls during quitting.  
>>> Basically,
>>> a simple get/set function is set up to denote when we the user has 
>>> confirmed
>>> a quit.
>>
>>
>>
>> My immediate concern is, does killed.exp leave a stopped binary around?
>>
>> Other than that I like it.
> 
> 
> I feel ill.
> 

I'm sorry to hear that.

> The first bug is in quit_force, so modifying throw_exeption to work 
> around it is a hack.  quit_force needs to catch any errors thrown by the 
> target vector.
> 
> Looking at the function's body.  I think the first part:
> 
>>   /* An optional expression may be used to cause gdb to terminate with 
>> the      value of that expression. */
>>   if (args)
>>     {
>>       struct value *val = parse_and_eval (args);
>>
>>       exit_code = (int) value_as_long (val);
>>     }
> 
> 
> should still be allowed to error out.  Otherwize something like:
> 
>     (gdb) exit bogus operand
> 
> will quit gdb denying the user of an oportunity to enter the correct 
> command.  The target calls and (I guess) the write_history should be 
> captured:
> 
>>   if (! ptid_equal (inferior_ptid, null_ptid) && target_has_execution)
>>     {
>>       if (attach_flag)
>>         target_detach (args, from_tty);
>>       else
>>         target_kill ();
>>     }
>>
>>   /* UDI wants this, to kill the TIP.  */
>>   target_close (1);
>>
>>   /* Save the history information if it is appropriate to do so.  */
>>   if (write_history_p && history_filename)
>>     write_history (history_filename);
> 
> 
> Also putting the do_final_cleanups inside the safety net would also 
> probably be for the best.
> 
>>   do_final_cleanups (ALL_CLEANUPS);     /* Do any final cleanups 
>> before exiting 
> 
> 

Ok, your idea is much better.  I have reworked the patch to use catch_errors().  I prepended the
message "Quitting: " so users will know that even though there is an error message
appended, it is still quitting.  I could optionally have put "Error quitting: "
but I thought the former was a better choice.

New patch attached.

2003-09-11  Jeff Johnston  <jjohnstn@redhat.com>

	* top.c (quit_target): New static helper function.
	(quit_force): Moved code to quit_target().  Call quit_target()
	via catch_errors() to catch errors during quit.

Ok to commit?

-- Jeff J.

> 
> 
> 
> The second less urgent bug is in the target code.  The target code 
> should catch the error and then force itself to be popped (then 
> rethrowing the error I guess).  That would have ensured that forward 
> progress was made and that second quit attemt worked.
> 
> Andrew
> 
> 

[-- Attachment #2: killed-patch2 --]
[-- Type: text/plain, Size: 1834 bytes --]

Index: top.c
===================================================================
RCS file: /cvs/src/src/gdb/top.c,v
retrieving revision 1.75
diff -u -r1.75 top.c
--- top.c	16 Aug 2003 18:38:46 -0000	1.75
+++ top.c	11 Sep 2003 19:42:03 -0000
@@ -1439,28 +1439,25 @@
   return 1;
 }
 
-/* Quit without asking for confirmation.  */
+/* Helper routine for quit_force that requires error handling.  */
 
-void
-quit_force (char *args, int from_tty)
+struct qt_args
 {
-  int exit_code = 0;
-
-  /* An optional expression may be used to cause gdb to terminate with the 
-     value of that expression. */
-  if (args)
-    {
-      struct value *val = parse_and_eval (args);
+  char *args;
+  int from_tty;
+};
 
-      exit_code = (int) value_as_long (val);
-    }
+static int
+quit_target (void *arg)
+{
+  struct qt_args *qt = (struct qt_args *)arg;
 
   if (! ptid_equal (inferior_ptid, null_ptid) && target_has_execution)
     {
       if (attach_flag)
-	target_detach (args, from_tty);
+        target_detach (qt->args, qt->from_tty);
       else
-	target_kill ();
+        target_kill ();
     }
 
   /* UDI wants this, to kill the TIP.  */
@@ -1471,6 +1468,29 @@
     write_history (history_filename);
 
   do_final_cleanups (ALL_CLEANUPS);	/* Do any final cleanups before exiting */
+
+  return 0;
+}
+
+/* Quit without asking for confirmation.  */
+
+void
+quit_force (char *args, int from_tty)
+{
+  int exit_code = 0;
+
+  /* An optional expression may be used to cause gdb to terminate with the 
+     value of that expression. */
+  if (args)
+    {
+      struct value *val = parse_and_eval (args);
+
+      exit_code = (int) value_as_long (val);
+    }
+
+  /* We want to handle any quit errors and exit regardless.  */
+  catch_errors (quit_target, args,
+	        "Quitting: ", RETURN_MASK_ALL);
 
   exit (exit_code);
 }

  reply	other threads:[~2003-09-11 20:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-05 15:54 J. Johnston
2003-09-05 15:58 ` Daniel Jacobowitz
2003-09-05 18:01   ` J. Johnston
2003-09-10 18:36   ` Andrew Cagney
2003-09-11 20:11     ` J. Johnston [this message]
2003-09-11 22:38       ` Andrew Cagney
2003-09-12 15:38         ` J. Johnston

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=3F60D701.8060200@redhat.com \
    --to=jjohnstn@redhat.com \
    --cc=ac131313@redhat.com \
    --cc=drow@mvista.com \
    --cc=gdb-patches@sources.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