From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2529 invoked by alias); 15 May 2014 13:24:15 -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 2520 invoked by uid 89); 15 May 2014 13:24:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,LIKELY_SPAM_BODY,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=no 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:24:13 +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 s4FDOAM8003541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 May 2014 09:24:11 -0400 Received: from blade.nx (ovpn-116-48.ams2.redhat.com [10.36.116.48]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s4FDO91v016423; Thu, 15 May 2014 09:24:10 -0400 Received: by blade.nx (Postfix, from userid 1000) id 1D42C2623DD; Thu, 15 May 2014 14:24:09 +0100 (BST) Date: Thu, 15 May 2014 13:24:00 -0000 From: Gary Benson To: Pedro Alves Cc: Mark Kettenis , gdb-patches@sourceware.org Subject: Re: [PATCH 0/2] Demangler crash handler Message-ID: <20140515132408.GC13323@blade.nx> 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> <537242D9.7080101@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <537242D9.7080101@redhat.com> X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00225.txt.bz2 Pedro Alves wrote: > On 05/13/14 11:21, Gary Benson wrote: > > 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. :-) I don't think anybody here really wants to be the demangler maintainer. Trouble is, I'm not sure anybody in GCC land wants to be it either! I wasn't really trying to disown myself from libiberty ownership. I guess what I was trying to say is the bulk of libiberty contributions come from GCC, but that GCC is not a heavy consumer of libiberty. We're eating their dogfood :) > > * 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? If there was somebody here with a deep knowledge of C++ and a deep knowledge of all the different mangling schemes we need to support then maybe. I'm not that person though. And it's not a small project: $ wc -l libiberty/*dem* 6386 libiberty/cp-demangle.c 174 libiberty/cp-demangle.h 232 libiberty/cp-demint.c 4869 libiberty/cplus-dem.c 11661 total If we're going to spend a lot of time on something we should spend it improving the existing demangler rather than trying to roll our own. The existing demangler is *good*, it just maybe hasn't had quite the beating that it gets from a GDB run on a big app using all kinds of the latest and greatest C++ features. > Or, can we perhaps extend the demangler a little to make it more > robust itself? I'm not sure. There's nothing obvious I can think of. I see you wrote another email with some ideas, I'll reply to that separately. > 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. Again, I'm not sure, unless you were to break it open and unit test the various components. It'd need careful refactoring to allow this without breaking the API. > Though a fuzzy tester that throws pseudo-random symbols at it would > be a nice project on its own.) I have a fuzzer for it. . Depressingly it gets a segfault in seconds every time. There seem to be at least three different issues. > > * 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. Maybe, I'm not sure who you'd ask though. All mail to gcc-patches with "mangl" in the subject ends up in my inbox, so the stuff is at least getting extra scrutiny from me :) Unless of course the subject is something useless like "PR 12345" (a pet hate of mine!) > It's not clear to me whether the issues are with demangling itself > being complex, or with the current implementation. A bit of both I think. Cheers, Gary -- http://gbenson.net/