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

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

[Markus Deuling]

Hi,

I work on that bug: http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb (Bug #2199)

If GDB debugs a remote target using gdbserver and steps over pthread_create() and the new thread uses dlopen(), then GDB "forgets" the step_resume breakpoint. An example:

(gdb) br main
Breakpoint 1 at 0x80485f5: file main.c, line 23.
(gdb) c
Continuing.
[New Thread 27027]
[Switching to Thread 27027]

Breakpoint 1, main () at main.c:23
23        for (cnt = 0; cnt < max_nr; cnt++)
(gdb) n
25            val = pthread_create (&thread_id[cnt], NULL, &test, NULL);
(gdb)
[New Thread 27028]
[New Thread 27031]

Program exited normally.
(gdb)

Normally, 4 threads would have been created instead of two! GDB looses the step_resume bp in the "main"
thread. If GDB debugs the application native this problem doesn't occur. Btw, this problems occurs
on x86 and ppc(64) and I state on every other linux arch also.

So I compared the behavior of native and remote debugging. I looked at the resuming of threads. After 
pthread_create() the original thread is resumed when debugging native. Remote debugging causes GDB to
always resume the last thread created (the one with dlopen)! I looked at gdbserver and found a patch which kills the symptom for my example:


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?

If that patch is ok, I'll re-send it with ChangeLog etc.

Thank you for reading this :-)

Regards,
Markus

-- 
Markus Deuling
GNU Toolchain for Linux on Cell BE
deuling@de.ibm.com 

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

[Daniel Jacobowitz]

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