From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27779 invoked by alias); 11 Jan 2004 20:46: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 27771 invoked from network); 11 Jan 2004 20:46:02 -0000 Received: from unknown (HELO localhost.redhat.com) (65.49.3.48) by sources.redhat.com with SMTP; 11 Jan 2004 20:46:02 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 150052B8F; Sun, 11 Jan 2004 15:46:01 -0500 (EST) Message-ID: <4001B608.2010607@gnu.org> Date: Sun, 11 Jan 2004 20:46:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 MIME-Version: 1.0 To: Jeff Johnston Cc: gdb-patches@sources.redhat.com, Elena Zannoni Subject: Re: [RFA]: error_silent for use in pending breakpoint support References: <3FE21F2B.3030104@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-01/txt/msg00293.txt.bz2 > To properly support pending breakpoints, gdb needs to be able to suppress the "not found" messages at will, but it also needs to sometimes issue these messages and determine the cause of the error was a "not found" event. > > To handle the problem, I propose two new useful functions in utils.c. The first is error_silent() which works just like error(), only it does not issue the error message. Like error(), it stores the error message in gdb_lasterr. This leads to the other new function: error_last_output() which is used to output the last error message. > > This allows the pending breakpoint support to issue the error message when the user is doing the initial break command and to suppress it when shared libraries are being loaded or a pending breakpoint is reenabled. (I noticed this mentioned linespec so left it, it's really more of a change to utils though). What does the stack look like at the point where error_silent is being called? I'm thinking that something more like: catch_exception_error (....., &error_mesg); with throw_error (message, ...) // silent or catch_exception_silently (..., &error_mesg); with error (message, ...) would be better. With that it should be possible to avoid the stateful error_last_output interface. I think this would also be better long term as it should lend itself to the recursive case (where an error is being propogated up the stack). Andrew