From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73078 invoked by alias); 21 May 2019 07:35:26 -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 73067 invoked by uid 89); 21 May 2019 07:35:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Received:Tue, 1.5 X-HELO: mail-wr1-f65.google.com Received: from mail-wr1-f65.google.com (HELO mail-wr1-f65.google.com) (209.85.221.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 21 May 2019 07:35:24 +0000 Received: by mail-wr1-f65.google.com with SMTP id d9so4344317wrx.0 for ; Tue, 21 May 2019 00:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=XOYT/UoqRcHhEv4y7pe+AXRhdAUgPVw/RCbHsZMp8Vo=; b=bsr/pivKR2q8ldmK0NnF3xJDIVPnAwzGyB9Wda60B2Iyjgog7czLUWK9aSIKfRNYl+ 5HIlnvT77y5gnXfJH1MXbR5KDQqkcXbS0VR0ovgEQmdjm+iQWe6AaNdU4ZMkbEcLV+Ye Hu+uIICtdgN/LOSQQlBPT2xNI/5x4BkuJalYR3Wo/8D7fQ9Ko7x5pzpCgfqwl2HOpR8O UcSrLnXRiqkT2hGnd23c33M2UWp/gmC6JAA7Z2iQ3/LbVmlCBTBXEXKGPVwG0mqaWRR+ aPUmILNKsvXi4OlTiBIbLq0mTcaD/sb6SlWKkjRrskQErKwD4QueiNkA+gdUuA7kvUQV PDsQ== Return-Path: Received: from localhost (cust64-dsl91-135-5.idnet.net. [91.135.5.64]) by smtp.gmail.com with ESMTPSA id h188sm4142274wmf.48.2019.05.21.00.35.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 21 May 2019 00:35:21 -0700 (PDT) Date: Tue, 21 May 2019 07:35:00 -0000 From: Andrew Burgess To: Tom Tromey Cc: Philippe Waroquiers , gdb-patches@sourceware.org Subject: Re: [PATCH v2 0/8] Demangle minimal symbol names in worker threads Message-ID: <20190521073520.GD2568@embecosm.com> References: <20190518210010.27697-1-tom@tromey.com> <1558274338.1454.13.camel@skynet.be> <87a7figtpz.fsf@tromey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87a7figtpz.fsf@tromey.com> X-Fortune: All the simple programs have been written. X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00465.txt.bz2 * Tom Tromey [2019-05-19 12:55:04 -0600]: > >>>>> "Philippe" == Philippe Waroquiers writes: > > Philippe> That looks like a nice startup speed improvement, will be much appreciated > Philippe> when debugging big executables at work :). > > Philippe> I however do not observe much parallel CPU being used. > Philippe> What type of operations will be mostly helped by parallel threads ? > > With this series, only demangling of minimal symbols is parallelized. > This does not dominate startup except in unusual situations, maybe a > very large C++ library that has no debuginfo and is unstripped. > > Locally I only saw utilization of 1.5 CPUs or so -- so, not very > parallel yet. > > The real point of this series is to flush out some of the lower-level > problems with having threading in gdb, so we can use it in more places. > For example, in this series, the SEGV handler stuff; but also this was > the reason for the big exception handling changes. > > A better win, I think, would be to parallelize partial symbol reading in > dwarf2read.c. This is a bit tricky... there are cross-CU references to > consider, and also the bcache seems like a point of contention. I've > been wondering if, instead, it would make sense to change the DWARF > reader not to make partial symbols at all. > > Philippe> One comment about 'maint set|show enable-threads' : > Philippe> what is the reason to have this as a maintenance command ? > > I see it as a setting for gdb developers, not gdb users. In fact, v1 > didn't have this, but John wanted a way to disable threading for > debugging gdb. > > Philippe> Also, maybe it would be better to have this setting being the > Philippe> maximum nr of threads to use. In some environments (e.g. > Philippe> operational environments), one might want to limit the nr of threads > Philippe> used by GDB. > > I think that most users don't know what most programs do under the hood; > nor should they need to. I suppose in some extreme situation maybe > someone would want to do this, but disabling threading in this case > should be good enough. Users like this should probably use gdbserver > instead though. Sorry for being really slow, but how does gdbserver help here? The threads are to help GDB parse the symbols/debug information from the ELF, right? In most cases GDB will still be parsing the symbols/debug from the ELF at the GDB end, not the gdbserver end. > > Philippe> Note also that I see GDB is starting some threads by default > Philippe> when guile is configured in, and 'maint set enable-threads off' > Philippe> seems to not disable this type of threading. > > Guile creates threads by default. In general gdb can't control the > threads made by either Guile or Python, because those can be made by > scripts created at runtime. Sure, but I think there's a difference between threads the user has specifically _asked_ GDB to create (through a script) and threads that are started to support some builtin GDB feature. Most users don't build their own GDB (I assume) so don't choose to enable guile support or not, so I think it probably is worth mentioning that the guile threads can't be disabled with this flag. Thanks, Andrew