From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24090 invoked by alias); 5 Sep 2003 15:54:03 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 23405 invoked from network); 5 Sep 2003 15:53:59 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 5 Sep 2003 15:53:59 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 813A18003B1 for ; Fri, 5 Sep 2003 11:53:55 -0400 (EDT) Message-ID: <3F58B193.5090400@redhat.com> Date: Fri, 05 Sep 2003 15:54:00 -0000 From: "J. Johnston" Organization: Red Hat Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gdb-patches@sources.redhat.com Subject: RFC: fix problems with errors during quitting (killed.exp) Content-Type: multipart/mixed; boundary="------------020507030403070209090005" X-SW-Source: 2003-09/txt/msg00067.txt.bz2 This is a multi-part message in MIME format. --------------020507030403070209090005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1609 The following patch fixes the problem that occurs when an error happens while quitting. Often an error() call gets triggered and the poor user is thrown back to the gdb command line where they try to quit again. I made an attempt to fix a similar problem by handling ptrace errors in quitting, however, thread-db.c gets into multiple precarious situations because it has to rely on libthread_db for information. When the thread has been killed/maimed, it gets errors when they are not expected and quitting becomes impossible. 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. If we get into top.c:throw_exception() and quit has been confirmed, it exits the program. This handles any number of messy kill scenarios and causes no regressions in the current testsuite. It fixes gdb.threads/killed.exp. I made the functions external so other parts of gdb can register a confirmed quit if necessary. I could make these routines static if this feature is not needed. I chose to exit with the code being passed on the jump. There may be a better constant choice. If anyone can think of scenario that this code is not going to handle correctly that might not be exercised by the testsuite, please let me know. Tested on x86 and ia64. Comments? 2003-09-04 Jeff Johnston * top.h (get_quit_confirmed, set_quit_confirmed): New prototypes. * top.c (get_quit_confirmed, set_quit_confirmed): New functions. (throw_exception): If quit confirmed, exit instead of jumping. --------------020507030403070209090005 Content-Type: text/plain; name="kill-error.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kill-error.patch" Content-length: 2489 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 4 Sep 2003 21:34:25 -0000 @@ -341,6 +341,9 @@ to that call via setjmp's return value. Note that REASON can't be zero, by definition in defs.h. */ + if (get_quit_confirmed ()) + exit ((int) reason); + (NORETURN void) SIGLONGJMP (*catch_return, (int) reason); } @@ -546,6 +549,21 @@ return catch_errors (do_captured_command, &args, "", mask); } +/* Flag to indicate if quit has been performed. */ +static int quit_confirmed; + +/* Verify if end-user has performed a quit operation. */ +int +get_quit_confirmed (void) +{ + return quit_confirmed; +} + +void +set_quit_confirmed (int val) +{ + quit_confirmed = val; +} /* Handler for SIGHUP. */ @@ -560,6 +578,7 @@ { caution = 0; /* Throw caution to the wind -- we're exiting. This prevents asking the user dumb questions. */ + set_quit_confirmed (1); quit_command ((char *) 0, 0); return 0; } @@ -771,6 +790,7 @@ (*window_hook) (instream, get_prompt ()); quit_flag = 0; + set_quit_confirmed (0); if (instream == stdin && stdin_is_tty) reinitialize_more_filter (); old_chain = make_cleanup (null_cleanup, 0); @@ -836,6 +856,7 @@ while (instream && !feof (instream)) { quit_flag = 0; + set_quit_confirmed (0); if (instream == stdin && stdin_is_tty) reinitialize_more_filter (); old_chain = make_cleanup (null_cleanup, 0); @@ -1422,6 +1443,8 @@ { char *s; + set_quit_confirmed (0); + /* This is something of a hack. But there's no reliable way to see if a GUI is running. The `use_windows' variable doesn't cut it. */ @@ -1436,6 +1459,7 @@ return 0; } + set_quit_confirmed (1); return 1; } Index: top.h =================================================================== RCS file: /cvs/src/src/gdb/top.h,v retrieving revision 1.9 diff -u -r1.9 top.h --- top.h 8 Jun 2003 18:27:14 -0000 1.9 +++ top.h 4 Sep 2003 21:34:25 -0000 @@ -42,6 +42,8 @@ void (*execute_command_func) (char *, int)); extern int quit_confirm (void); +extern int get_quit_confirmed (void); +extern void set_quit_confirmed (int); extern void quit_force (char *, int); extern void quit_command (char *, int); extern int quit_cover (void *); --------------020507030403070209090005--