From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25561 invoked by alias); 13 May 2014 16:05:51 -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 25442 invoked by uid 89); 13 May 2014 16:05:50 -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; Tue, 13 May 2014 16:05:49 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4DG5lF9001789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 May 2014 12:05:48 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s4DG5k8Q000303; Tue, 13 May 2014 12:05:46 -0400 Message-ID: <537242D9.7080101@redhat.com> Date: Tue, 13 May 2014 16:05: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: Gary Benson , Mark Kettenis CC: gdb-patches@sourceware.org Subject: Re: [PATCH 0/2] Demangler crash handler References: <20140509100656.GA4760@blade.nx> <201405091120.s49BKO1f010622@glazunov.sibelius.xs4all.nl> <20140509153305.GA13345@blade.nx> <201405112023.s4BKNL3v024248@glazunov.sibelius.xs4all.nl> <20140513102134.GB17805@blade.nx> In-Reply-To: <20140513102134.GB17805@blade.nx> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-05/txt/msg00162.txt.bz2 On 05/13/14 11:21, Gary Benson wrote: > I'd argue that the demangler warrants special consideration as > in one sense it's not a subsystem of GDB but rather a (somewhat > unloved?) side-project of GCC that we borrow. The situation > we find ourselves in is this: > > * GDB is more likely to see demangler crashes than libstdc++ True. > > GDB demangles all symbols in every file it loads, always. In > libstdc++ the demangler is only called in error situations, > and then only to demangle the few symbols that appear in the > backtrace. > > So: we get the bug reports, and have to triage them, even > though the code is not "ours". I really can't agree with the "not ours" sentiment. Not if we think in terms of the GNU toolchain. IMO, we should foremost think of ourselves as development toolchain toolsmiths over gdb hackers. Thought experiment #1: I hereby declare that the demangler maintainers are GDB hackers. In order to get one's code in the demangler, one has to get it past those specific (and very busy) GDB hackers. Thought experiment #2: I'm going to import and fork the demangler into gdb/ directly, and declare that from here on, we get to fix it ourselves. Either case doesn't seem to make a difference to me. Except that with #2, we'd end with an incompetent demangler maintainer. :-) > * Bugs have a more serious affect on GDB than on libstdc++ True. > > Currently a demangler crash will cause GDB to segfault, usually at > startup. A demangler crash in libstdc++ is not such a big deal as > the application was likely crashing anyway. > > So: bugs that are high-priority for us are low-priority for the > "main" demangler authors, and we end up having to fix them. True. So... Since this subsystem is so important, should we write our own demangler from scratch then? Would that result in a better outcome? Or, can we perhaps extend the demangler a little to make it more robust itself? Is there something that could be done to demangler's testsuite to make it more effective in catching bugs that GDB would catch? (I mean other than throwing more symbols at it. Though a fuzzy tester that throws pseudo-random symbols at it would be a nice project on its own.) > > * Demangler patches often get waved through with minimal scrutiny That does sound like a problem. Can we work with the gcc folks to somehow prevent this from happening? E.g., perhaps we could ask them to CC all demangler patches to the gdb-patches@ list as well, like supposedly done for some other shared files. > > The few people who really know the demangler are busy with other > things, and the above two points mean demangler issues are low- > priority for them. It's not clear to me whether the issues are with demangling itself being complex, or with the current implementation. In any case, this doesn't sound like a problem on their end, but on ours. But if the demangler was "ours", who would be doing the fixing anyway? -- Pedro Alves