Crazy?

Crazy?

[Mike Stump]

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?

Re: Crazy?

[Doug Evans]

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]

Re: Crazy?

[Mike Stump]

On Jun 17, 2015, at 2:26 PM, Doug Evans <dje@google.com> wrote:
> Can you try using one of the newer methods?
> [it's the with_ql version that uses CRAZY_MAX_THREADS]

Ah, I was mistaken:

remote_ops.to_find_new_threads = remote_threads_info;  

and yet:

static void
remote_find_new_threads (void)
{
  remote_threadlist_iterator (remote_newthread_step, 0,
                              CRAZY_MAX_THREADS);
}

I was assuming that I was going to go in through the top using this routine.  As you say, remote_threads_info doesn’t have the limitation, and since I  already use qfThreadInfo, I should be good.  I see that trunk already fixed up the names nicely.

Thanks.