From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6085 invoked by alias); 14 May 2014 16:08:50 -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 6075 invoked by uid 89); 14 May 2014 16:08:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-gw3-out.broadcom.com Received: from mail-gw3-out.broadcom.com (HELO mail-gw3-out.broadcom.com) (216.31.210.64) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 14 May 2014 16:08:48 +0000 Received: from irvexchcas08.broadcom.com (HELO IRVEXCHCAS08.corp.ad.broadcom.com) ([10.9.208.57]) by mail-gw3-out.broadcom.com with ESMTP; 14 May 2014 09:31:15 -0700 Received: from IRVEXCHSMTP1.corp.ad.broadcom.com (10.9.207.51) by IRVEXCHCAS08.corp.ad.broadcom.com (10.9.208.57) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 14 May 2014 09:08:46 -0700 Received: from mail-irva-13.broadcom.com (10.10.10.20) by IRVEXCHSMTP1.corp.ad.broadcom.com (10.9.207.51) with Microsoft SMTP Server id 14.3.174.1; Wed, 14 May 2014 09:08:47 -0700 Received: from [10.177.72.87] (unknown [10.177.72.87]) by mail-irva-13.broadcom.com (Postfix) with ESMTP id 808DC9F9F7 for ; Wed, 14 May 2014 09:08:46 -0700 (PDT) Message-ID: <5373950D.7050903@broadcom.com> Date: Wed, 14 May 2014 16:08:00 -0000 From: Andrew Burgess User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Subject: Re: [PATCH 0/2] Demangler crash handler References: <20140509100656.GA4760@blade.nx> <201405091120.s49BKO1f010622@glazunov.sibelius.xs4all.nl> <87fvkhjqvs.fsf@mid.deneb.enyo.de> <53737737.2030901@redhat.com> In-Reply-To: <53737737.2030901@redhat.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00211.txt.bz2 On 14/05/2014 3:01 PM, Pedro Alves wrote: > On 05/10/2014 09:55 PM, Florian Weimer wrote: >> * Mark Kettenis: >> >>> No. It's this skind of duct-tape that will make sure that bugs in the >>> demangler won't get fixed. Apart from removing the incentive to fix >>> the bugs, these SIGSEGV signal handlers make actually fixing the bugs >>> harder as you won't have core dumps. >> >> I find this approach extremely odd as well. > > I have to admit I'm not super keen on using signals for this either. > For one, not all bugs trigger segmentation faults. Then stealing > a signal handler always has multi-threading considerations. E.g., > gdb Python code could well spawn a thread that happens to call > something that wants its own SIGSEGV handler... Signal handlers > are per-process, not per-thread. > > 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. Given that, it's not clear to me where you'd want to use the error handler, if you know something can't be demangled then you'd return NULL, but if some feature wasn't implemented yet then surely you're still better returning NULL than using the error handler, at least that way the user of the demangler will continue using the mangled version of the symbol. I'm not arguing _for_ catching SEGV, I just think that an error handler only helps with known bad states, the problem is that I think in all known bad states the demangler should just return NULL, it's the unknown bad states that are an issue here. Thanks, Andrew