From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27841 invoked by alias); 14 May 2014 14:18:35 -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 27829 invoked by uid 89); 14 May 2014 14:18:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 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; Wed, 14 May 2014 14:18:33 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4EE1UDf000692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 May 2014 10:01:31 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s4EE1Rf8016611; Wed, 14 May 2014 10:01:29 -0400 Message-ID: <53737737.2030901@redhat.com> Date: Wed, 14 May 2014 14:18:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Florian Weimer , Mark Kettenis CC: gbenson@redhat.com, gdb-patches@sourceware.org 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> In-Reply-To: <87fvkhjqvs.fsf@mid.deneb.enyo.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-05/txt/msg00206.txt.bz2 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? extern void internal_error (const char *file, int line, const char *, ...) ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (3, 4); That's in the same spirit as bfd_set_error_handler, but for internal errors. The default implementation could just abort. /* This is a function pointer to the routine which should handle BFD error messages. It is called when a BFD routine encounters an error for which it wants to print a message. Going through a function pointer permits a program linked against BFD to intercept the messages and deal with them itself. */ bfd_error_handler_type _bfd_error_handler = _bfd_default_error_handler; bfd_error_handler_type bfd_set_error_handler (bfd_error_handler_type pnew) { bfd_error_handler_type pold; pold = _bfd_error_handler; _bfd_error_handler = pnew; return pold; } GDB would install a hook that would end up in internal_error, or warning, or whatever we decide is best. As bonus, we get the file/line number that triggered the bug. If libgcc/libstd++ don't want any sort of overhead, then we could make the assertions be nops under #if defined(IN_LIBGCC2) || defined(IN_GLIBCPP_V3) That is, the same conditions __cxa_demangle is under. Then we'd add a demangle_assert macro to the demangler, similar to gdb_assert, that calls that hook if the assertion fails. And then we could sprinkle the demangler with assertions. I think that'd be easy to do, and I'd think it's much cleaner and robust. -- Pedro Alves