Re: [RFC] remote step over pthread_create()/dlopen() bug

[Daniel Jacobowitz <drow at false dot org>]

On Wed, Jan 24, 2007 at 05:37:34PM +0100, Markus Deuling wrote:
> diff -urN src/gdb/gdbserver/linux-low.c dev/gdb/gdbserver/linux-low.c
> --- src/gdb/gdbserver/linux-low.c       2007-01-09 23:55:10.000000000 +0100
> +++ dev/gdb/gdbserver/linux-low.c       2007-01-24 17:27:45.000000000 +0100
> @@ -1078,8 +1078,11 @@
>      GDB removes the breakpoint to single-step a particular thread
>      past it, then re-inserts it and resumes all threads.  We want
>      to report the second thread without resuming it in the interim.  */
> -  if (process->status_pending_p)
> -    check_removed_breakpoint (process);
> +  if (process->status_pending_p)
> +    {
> +      check_removed_breakpoint (process);
> +      return 0;
> +    }
> 
>   if (process->status_pending_p)
>     * (int *) flag_p = 1;
> 
> Now the pending_flag for this process isn't set, which maybe cause 
> misbehavior in some ways.
> Now linux_queue_one_thread() isn't called. Instead 
> linux_continue_one_thread() is called and the
> original thread is resumed. 
> 
> I really would like to know your opinion about that patch. Is it ok to 
> apply or is there a better
> way to handle it? Do you see any problems resulting from that patch?

Sorry, I think that's the symptom, not the problem.  GDB stops every
thread when a new thread is created, but gdbserver is designed not to
do that - it performs better when there are a lot of threads.

So we expect the two cases (native and remote) to be different.  GDB
ought to handle either one correctly.

-- 
Daniel Jacobowitz
CodeSourcery