From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27495 invoked by alias); 8 Feb 2007 22:25:32 -0000 Received: (qmail 27449 invoked by uid 22791); 8 Feb 2007 22:25:30 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Thu, 08 Feb 2007 22:25:21 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1HFHhf-0000iO-4v; Thu, 08 Feb 2007 17:25:19 -0500 Date: Thu, 08 Feb 2007 22:25:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Catch errors in value_get_print_value Message-ID: <20070208222519.GA2611@nevyn.them.org> Mail-Followup-To: Nick Roberts , gdb-patches@sourceware.org References: <17858.21211.33629.685339@kahikatea.snap.net.nz> <20070208174131.GC13544@nevyn.them.org> <17867.41420.663991.707406@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17867.41420.663991.707406@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-02/txt/msg00110.txt.bz2 On Fri, Feb 09, 2007 at 11:18:52AM +1300, Nick Roberts wrote: > > > Currently when common_val_print throws an error from install_new_value it gets > > > caught in mi_execute_command and prints an MI error (^error,...) without > > > cleaning up. This patch catches the error in value_get_print_value so that GDB > > > can proceed normally. It could be adapted to output something like > > > "" but I think the empty string works better. > > > > Could you explain why? I would be confused to see an empty value in > > my locals window. That's separate from this bug though. > > It's much quieter than a window full of error/warning messages. If there's no > value available, the frontend doesn't show one. That seems logical to me but > perhaps only because I'm used to it. Well, maybe we could use in_scope="false" and no value, and let the front end decide... > Thanks. This is clearly a better patch as it's much simpler. Thinking more > generally, I wonder if there are other cases where value_contents_all should > catch this error? I don't think so - would there be a sensible return value for value_contents_all if something has gone wrong? Not really, so I think it's the responsibility of other layers to detect it. -- Daniel Jacobowitz CodeSourcery