From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10282 invoked by alias); 4 Jun 2014 15:52:13 -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 10225 invoked by uid 89); 4 Jun 2014 15:52:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f179.google.com Received: from mail-yk0-f179.google.com (HELO mail-yk0-f179.google.com) (209.85.160.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 04 Jun 2014 15:52:10 +0000 Received: by mail-yk0-f179.google.com with SMTP id 19so6218501ykq.10 for ; Wed, 04 Jun 2014 08:52:08 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.83.204 with SMTP id q52mr55500113yhe.65.1401897128248; Wed, 04 Jun 2014 08:52:08 -0700 (PDT) Received: by 10.170.150.70 with HTTP; Wed, 4 Jun 2014 08:52:08 -0700 (PDT) In-Reply-To: <538F3300.6010700@broadcom.com> References: <20140604100755.GA7570@blade.nx> <201406041027.s54ARXYL017073@glazunov.sibelius.xs4all.nl> <20140604133413.GA10121@blade.nx> <538F3300.6010700@broadcom.com> Date: Wed, 04 Jun 2014 15:52:00 -0000 Message-ID: Subject: Re: [PATCH 0/2 v3] Demangler crash handler From: Doug Evans To: Andrew Burgess Cc: Gary Benson , Mark Kettenis , "gdb-patches@sourceware.org" , Eli Zaretskii , Florian Weimer , Pedro Alves , Tom Tromey Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00172.txt.bz2 On Wed, Jun 4, 2014 at 7:53 AM, Andrew Burgess wrote: >> "Should" is the operative word here. It *should* not be necessary >> because the demangler *should* never crash. But this isn't utopia. >> The demangler is code, and code has bugs. People make mistakes. >> Things are valid now that may not be valid in the future. And GDB >> should not just crash if some symbol in the inferior isn't handled >> or doesn't make sense or whatever. > > By this logic should / would we not extend the SIGSEGV handler to cover > all gdb code? If the target is running in synchronous mode we'd > install our SEGV handler when the target stops and remove it when the > target restarts (asynchronous mode would need more thought), then any > bugs in gdb that cause a SEGV would result in a core dump ... > > I'm just not sure why the demangler should get special treatment. It has a very specific entry point, and thus adding one here is easy (setting aside the technicalities of the implementation). I'd say this is ok if only to provide a proving ground for whether this is useful in practice.