From: Tom Tromey <tom@tromey.com>
To: Andrew Burgess <andrew.burgess@embecosm.com>
Cc: Tom Tromey <tom@tromey.com>,
Philippe Waroquiers <philippe.waroquiers@skynet.be>,
gdb-patches@sourceware.org
Subject: Re: [PATCH v2 0/8] Demangle minimal symbol names in worker threads
Date: Tue, 21 May 2019 15:45:00 -0000 [thread overview]
Message-ID: <87a7ffg6b2.fsf@tromey.com> (raw)
In-Reply-To: <20190521073520.GD2568@embecosm.com> (Andrew Burgess's message of "Tue, 21 May 2019 08:35:20 +0100")
>>>>> "Andrew" == Andrew Burgess <andrew.burgess@embecosm.com> writes:
>> 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.
Andrew> Sorry for being really slow, but how does gdbserver help here? The
Andrew> threads are to help GDB parse the symbols/debug information from the
Andrew> ELF, right? In most cases GDB will still be parsing the symbols/debug
Andrew> from the ELF at the GDB end, not the gdbserver end.
My understanding is that the scenario is wanting to limit threads so
that one can run gdb on some resource-constrained machine. In this
situation it's better to run gdbserver on the limited machine and run
gdb on one's desktop.
>> 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.
Andrew> Sure, but I think there's a difference between threads the user has
Andrew> specifically _asked_ GDB to create (through a script) and threads that
Andrew> are started to support some builtin GDB feature.
It's mildly incorrect to say that the user asked for these threads. The
guile ones are created at startup regardless. Also, due to
auto-loading, the user may not be aware of precisely what Python is
running in gdb or what it is doing; though in this case it does seem
pretty unlikely for threading to be used.
I'll change the setting to control the number of threads.
Tom
next prev parent reply other threads:[~2019-05-21 15:45 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-18 21:00 Tom Tromey
2019-05-18 21:00 ` [PATCH v2 8/8] Add maint set/show enable-threads Tom Tromey
2019-05-22 5:01 ` Eli Zaretskii
2019-05-26 20:46 ` Tom Tromey
2019-05-27 2:32 ` Eli Zaretskii
2019-05-18 21:00 ` [PATCH v2 7/8] Demangle minsyms in parallel Tom Tromey
2019-05-18 21:00 ` [PATCH v2 6/8] Introduce thread-safe way to handle SIGSEGV Tom Tromey
2019-05-18 21:00 ` [PATCH v2 5/8] Introduce run_on_main_thread Tom Tromey
2019-05-18 21:00 ` [PATCH v2 2/8] Remove static buffer from ada_decode Tom Tromey
2019-05-18 21:00 ` [PATCH v2 4/8] Lock the demangled hash table Tom Tromey
2019-05-18 21:00 ` [PATCH v2 3/8] Add configure check for std::thread Tom Tromey
2019-05-18 21:00 ` [PATCH v2 1/8] Defer minimal symbol name-setting Tom Tromey
2019-05-19 13:59 ` [PATCH v2 0/8] Demangle minimal symbol names in worker threads Philippe Waroquiers
2019-05-19 18:55 ` Tom Tromey
2019-05-21 0:35 ` Philippe Waroquiers
2019-05-21 7:35 ` Andrew Burgess
2019-05-21 15:45 ` Tom Tromey [this message]
2019-05-21 16:21 ` Andrew Burgess
2019-05-31 2:48 ` Tom Tromey
2019-05-31 17:13 ` Philippe Waroquiers
2019-09-29 0:35 ` [PATCH] Don't use the mutex for each symbol_set_names call Christian Biesinger via gdb-patches
2019-09-30 14:18 ` Tom Tromey
2019-09-30 16:55 ` Christian Biesinger via gdb-patches
2019-10-02 17:18 ` Tom Tromey
2019-10-02 18:20 ` Christian Biesinger via gdb-patches
2019-10-02 22:02 ` Christian Biesinger via gdb-patches
2019-10-03 18:15 ` [PATCH v2 2/2] Precompute hash value for symbol_set_names Christian Biesinger via gdb-patches
2019-10-03 18:15 ` [PATCH v2 1/2] Don't use the mutex for each symbol_set_names call Christian Biesinger via gdb-patches
2019-09-30 21:45 ` [PATCH] " Christian Biesinger via gdb-patches
2019-10-01 17:02 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a7ffg6b2.fsf@tromey.com \
--to=tom@tromey.com \
--cc=andrew.burgess@embecosm.com \
--cc=gdb-patches@sourceware.org \
--cc=philippe.waroquiers@skynet.be \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox