[PATCH v2 0/8] Demangle minimal symbol names in worker threads
Andrew Burgess
andrew.burgess@embecosm.com
Tue May 21 07:35:00 GMT 2019
* 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
More information about the Gdb-patches
mailing list