From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4255 invoked by alias); 15 May 2014 13:25:32 -0000 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 Received: (qmail 4242 invoked by uid 89); 15 May 2014 13:25:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 15 May 2014 13:25:30 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4FDPSQk003912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 15 May 2014 09:25:28 -0400 Received: from blade.nx (ovpn-116-48.ams2.redhat.com [10.36.116.48]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s4FDPRhW017439; Thu, 15 May 2014 09:25:28 -0400 Received: by blade.nx (Postfix, from userid 1000) id 441A12623DD; Thu, 15 May 2014 14:25:27 +0100 (BST) Date: Thu, 15 May 2014 13:25:00 -0000 From: Gary Benson To: Pedro Alves Cc: Andrew Burgess , gdb-patches@sourceware.org Subject: Re: [PATCH 0/2] Demangler crash handler Message-ID: <20140515132527.GD13323@blade.nx> References: <20140509100656.GA4760@blade.nx> <201405091120.s49BKO1f010622@glazunov.sibelius.xs4all.nl> <87fvkhjqvs.fsf@mid.deneb.enyo.de> <53737737.2030901@redhat.com> <5373950D.7050903@broadcom.com> <5373B6C6.6060401@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5373B6C6.6060401@redhat.com> X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00226.txt.bz2 Pedro Alves wrote: > On 05/14/2014 05:08 PM, Andrew Burgess wrote: > > On 14/05/2014 3:01 PM, Pedro Alves wrote: > > > How about we instead add a new hook to the demangler interface, > > > that allows registering a callback that has the prototype of > > > gdb's internal_error? > > > > I thought that if the demangler couldn't demangle a symbol you > > just got back NULL indicating no demangle was possible. > > Well, that's fine, and I think that it's a matter that can be > changed independently of the scheme used to detect bad state > in the demangled. For instance, we can have GDB's > demangler_internal_error callback throw a normal error, and > then catch it from within gdb_demangle, and have that return > NULL. The demangler already has a system in place to handle early termination. It's not gdb_demangle that needs to return NULL: it's the demangler's API to return NULL if the symbol cannot be demangled. It's not clear to me what benefit a second system for early termination would add, or how you would decide which system to use for any given error. > ...the idea is about protecting against really bad state, not > unimplemented features. The thing is, everything's fine once you've *detected* the bad state: you can handle it however you want. Which, using the demangler's current convention, is either "handle the state" or "d_print_error (&dpi); return;". The whole point of the segfault catcher was to cope with undetected bad state. I'm not saying we should not try and fix more places where bad state is undetected. My point was that no matter how much work you put in you still can never say "ok, we got all the bugs now". That's what the segfault catcher was for. > We should really prevent that with better testing, e.g., the > demangle-the-world testing, and/or fuzzy testing. Agreed. If nothing else comes out of this discussion but more testing then it's all been worthwhile. Thanks, Gary -- http://gbenson.net/