Re: [PATCH v2 0/8] Demangle minimal symbol names in worker threads

[Andrew Burgess <andrew.burgess@embecosm.com>]

* Tom Tromey <tom@tromey.com> [2019-05-19 12:55:04 -0600]:

> >>>>> "Philippe" == Philippe Waroquiers <philippe.waroquiers@skynet.be> 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