From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12817 invoked by alias); 4 Nov 2004 00:09:41 -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 12755 invoked from network); 4 Nov 2004 00:09:34 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 4 Nov 2004 00:09:34 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iA409XsV022672 for ; Wed, 3 Nov 2004 19:09:34 -0500 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iA409Wr21996; Wed, 3 Nov 2004 19:09:33 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 95D62129D8C; Wed, 3 Nov 2004 19:09:26 -0500 (EST) Message-ID: <41897333.6070201@gnu.org> Date: Thu, 04 Nov 2004 00:09:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: Joel Brobecker , Jeff Johnston Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA]: issue warnings for frame offenses References: <417EBFF9.5060104@redhat.com> <20041026213037.GR1039@gnat.com> In-Reply-To: <20041026213037.GR1039@gnat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00051.txt.bz2 Joel Brobecker wrote: >>The attached patch changes a few backtrace termination scenarios in frame.c >>to issue a warning and terminate the backtrace rather than use the error() >>function. The change is being made to help out end-users that use macros >>with backtraces in them. At present, there a number of platforms where >>backtraces through assembler code (e.g. glibc thread creation) cause >>backtraces to get somewhat lost. When the frame code issues the error, any >>macro issuing the backtrace is terminated. If an end-user is applying such >>a macro to all threads, it ends prematurely for no good reason. With the >>change, the message is still issued and the backtrace is stopped. > > > Interestingly, a customer of ours reported about a year or two ago > a situation similar to this. They were using the backtrace command > inside breakpoint commands looking like this: > > break somewhere > commands > backtrace > continue > end > > The idea was that they wanted to see how the program would get to > a certain piece of code (in our case raise an exception), and how > often. But they didn't want to stop the execution and start debugging. > But the unwinder would sometimes be confused, and an error would be > raised, and the commands execution would be aborted. > > We modified the debugger in a rather radical way: We wrapped the > backtrace command under control of the catch_error() routine, and > transformed any error into a warning. We didn't feel that this would > be interesting for the FSF tree, but maybe our assesment was wrong. > Let us know if this approach would also be useful, in which case > we'll be happy to contribute it. (Somewhere there is a try / finally command patch, just waiting to be integrated.) How does the following sound: - add a new fatal_error(): There should be a new error mechanism that throws a QUIT instead of ERROR. Code should not normally be catching QUIT (much unfortunately does). A fatal error is things like: syntax error; no target; lost target. Things like a memory access violation though are not fatal. - think about stopping code catching and then discarding QUIT Grep for RETURN_MASK_ALL in the sources - it should be RETURN_MASK_ERROR :-/ - modify the backtrace code to catch ERROR, but not QUIT Along the lines of Joel's suggestion, the backtrace command should catch ERROR (but should not catch QUIT). That way simple problems don't abort the script but fatal ones do. Why? Lets try to categorize commands as being of two types: - display These commands print information from the inferior. In general they don't cause an error - for instance: (gdb) print *(char *)0 $1 = (yes I know, this isn't currently the case :-) - modify These commands try to change the state of GDB or the inferior. In general problems do lead to an error as not performing the operation puts things into a relatively undefined state. (The pedant will realize that ``(gdb) print (*(char *)0)++'' can be thought of as a `modify', lets ignore that in this simple model :-). The breakpoint command falls into the ``display'' category. The up and run commands fall into the ``modify'' category. Why not s/error/warning/: I'm trying to avoid a bigger mess. Given a corrupt stack, I'm pretty sure that this: (gdb) up Previous frame identical to this frame (corrupt stack?) (gdb) up Initial frame selected; you cannot go up. (the same error should be printed both times) and this: (gdb) frame 0x12345678 Previous frame identical to this frame (corrupt stack?) (gdb) frame 0x12345678 #1 0x1005e5f8 in fprintf_filtered .... (the error should be completely suppressed) occur! Fixing this would mean more radical (but still overdue) changes to both the stack and frame code. My guess is publish a method: int safe_get_prev_frame (this_frame, &prev_frame, &error_if_nonnull) and use that. How, if you're up for a challenge. Andrew