From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9998 invoked by alias); 4 Nov 2004 16:29:48 -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 9866 invoked from network); 4 Nov 2004 16:29:45 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 4 Nov 2004 16:29:45 -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 iA4GTjgP027673 for ; Thu, 4 Nov 2004 11:29:45 -0500 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iA4GTdr17626; Thu, 4 Nov 2004 11:29:39 -0500 Received: from touchme.toronto.redhat.com (IDENT:postfix@touchme.toronto.redhat.com [172.16.14.9]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id iA4GTdbU019774; Thu, 4 Nov 2004 11:29:39 -0500 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 4DE2D80002E; Thu, 4 Nov 2004 11:29:39 -0500 (EST) Message-ID: <418A58F3.8000603@redhat.com> Date: Thu, 04 Nov 2004 16:29:00 -0000 From: Jeff Johnston User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 MIME-Version: 1.0 To: Andrew Cagney Cc: Joel Brobecker , gdb-patches@sources.redhat.com Subject: Re: [RFA]: issue warnings for frame offenses References: <417EBFF9.5060104@redhat.com> <20041026213037.GR1039@gnat.com> <41897333.6070201@gnu.org> In-Reply-To: <41897333.6070201@gnu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00062.txt.bz2 Andrew Cagney wrote: > 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: > Sounds fine. I'll start working on it. I assume you meant non_fatal_error below for the new function that issues the quit. > - 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 >