This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Crazy?
- From: Doug Evans <dje at google dot com>
- To: Mike Stump <mikestump at comcast dot net>
- Cc: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Wed, 17 Jun 2015 16:26:56 -0500
- Subject: Re: Crazy?
- Authentication-results: sourceware.org; auth=none
- References: <57BF10A2-F13E-4399-8D18-A662681F5384 at comcast dot net>
On Wed, Jun 17, 2015 at 12:26 PM, Mike Stump <mikestump@comcast.net> wrote:
> In remote.c we have:
>
> #define CRAZY_MAX_THREADS 1000
>
> We need something that is either bigger, or obtainable from the target. If bigger, I can just hack my sources to be different. If obtainable from the target, weâll Iâd let someone pick a q spelling for it and I could try my hand at implementing it. Another solution is to just trust the target and remove the limit altogether. I kinda like the last option. I canât imagine a developer would ever be saved by the limit.
>
> So, would removal of the limit be reasonable?
Hi.
By "bigger" do you mean more threads?
The value isn't so much a maximum number of threads but the number of
times gdb requests a thread list from the target.
If the target returned one thread per iteration then, yeah, that's the
max number of threads.
But I also see this:
/* About this many threadisds fit in a packet. */
#define MAXTHREADLISTRESULTS 32
So if the target returned 32 threads per request then the max is
32000, which is more useful
(1000 threads is not unheard of).
Presumably the max is there so that bugs in the remote server don't hang gdb,
which is reasonable, so we don't want to remove the limit.
We could increase the limit though without much harm I think.
>From reading the source I gather this way of getting the thread list is old:
/* We have a few different mechanisms to fetch the thread list. Try
them all, starting with the most preferred one first, falling
back to older methods. */
if (remote_get_threads_with_qxfer (ops, &context)
|| remote_get_threads_with_qthreadinfo (ops, &context)
|| remote_get_threads_with_ql (ops, &context))
Can you try using one of the newer methods?
[it's the with_ql version that uses CRAZY_MAX_THREADS]