This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[RFC] remote step over pthread_create()/dlopen() bug
- From: Markus Deuling <deuling at de dot ibm dot com>
- To: GDB Patches <gdb-patches at sourceware dot org>
- Date: Wed, 24 Jan 2007 17:37:34 +0100
- Subject: [RFC] remote step over pthread_create()/dlopen() bug
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