From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25303 invoked by alias); 19 May 2019 13:59:25 -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 25295 invoked by uid 89); 19 May 2019 13:59:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=operational, HX-Languages-Length:2210, helped X-HELO: mailsec109.isp.belgacom.be Received: from mailsec109.isp.belgacom.be (HELO mailsec109.isp.belgacom.be) (195.238.20.105) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 19 May 2019 13:59:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skynet.be; i=@skynet.be; q=dns/txt; s=securemail; t=1558274362; x=1589810362; h=message-id:subject:from:to:date:in-reply-to:references: mime-version:content-transfer-encoding; bh=4Baza9uarxUXsez8/hs1UUdRxviJvs3Whkl/8cwBwzo=; b=eEI5gLuIhqb5EwXp0d2Y1k/0vWmKby2MRHCK3kCeKfcg1ZuXBk/OySWv qsZJgxbD5AW14rwWiIUE4NPEl8JTXw==; Received: from 161.32-242-81.adsl-dyn.isp.belgacom.be (HELO md) ([81.242.32.161]) by relay.skynet.be with ESMTP/TLS/AES256-GCM-SHA384; 19 May 2019 15:58:59 +0200 Message-ID: <1558274338.1454.13.camel@skynet.be> Subject: Re: [PATCH v2 0/8] Demangle minimal symbol names in worker threads From: Philippe Waroquiers To: Tom Tromey , gdb-patches@sourceware.org Date: Sun, 19 May 2019 13:59:00 -0000 In-Reply-To: <20190518210010.27697-1-tom@tromey.com> References: <20190518210010.27697-1-tom@tromey.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00457.txt.bz2 On Sat, 2019-05-18 at 15:00 -0600, Tom Tromey wrote: > This is v2 of my patch series to demangle minimal symbol names in > worker threads. > > v1 was here: > > https://sourceware.org/ml/gdb-patches/2019-03/msg00211.html > > I think this version addresses all the comments, in particular it adds > a simple way to disable threading, and adds some configury. > > Regression tested by the buildbot. At one point this was failing most > tests on the i686 builder, but I couldn't reproduce this with my own > i686 build (on the GCC compile farm), and various checks involving > running parts of the test suite on the buildbot using valgrind did not > show anything. In the end, the problem seems to have gone away > (though there are many gdb.arch failures on i686 -- assertion failures > in libopcodes). So, I'm not totally sure what to make of this. That looks like a nice startup speed improvement, will be much appreciated when debugging big executables at work :). HEAD: time ../build_binutils-gdb/gdb/gdb --nx -batch -ex 'info var tructructruc' ./gdb/gdb ... real 0m3.902s user 0m3.068s sys 0m0.836s worker thread patch: time ./gdb/gdb --nx -batch -ex 'info var tructructruc' ./gdb/gdb ... real 0m2.379s user 0m2.172s sys 0m0.284s I however do not observe much parallel CPU being used. What type of operations will be mostly helped by parallel threads ? One comment about 'maint set|show enable-threads' : what is the reason to have this as a maintenance command ? Also, maybe it would be better to have this setting being the maximum nr of threads to use. In some environments (e.g. operational environments), one might want to limit the nr of threads used by GDB. So, maybe 'maint set enable-threads' might be replaced by something like: set max-gdb-threads (NUMBER | unlimited) where unlimited means to use the max permitted by the implementation (or similar wording as in std::thread::hardware_concurrency), and where 0 will disable threading. Note also that I see GDB is starting some threads by default when guile is configured in, and 'maint set enable-threads off' seems to not disable this type of threading. Thanks Philippe