From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17511 invoked by alias); 24 Jan 2007 16:37:57 -0000 Received: (qmail 17502 invoked by uid 22791); 24 Jan 2007 16:37:55 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate4.de.ibm.com (HELO mtagate4.de.ibm.com) (195.212.29.153) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 24 Jan 2007 16:37:45 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id l0OGbgOo202294 for ; Wed, 24 Jan 2007 16:37:42 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0OGbg953088480 for ; Wed, 24 Jan 2007 17:37:42 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0OGbgTF029278 for ; Wed, 24 Jan 2007 17:37:42 +0100 Received: from [9.152.248.39] (dyn-9-152-248-39.boeblingen.de.ibm.com [9.152.248.39]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0OGbgYw029275 for ; Wed, 24 Jan 2007 17:37:42 +0100 Message-ID: <45B78B4E.8050903@de.ibm.com> Date: Wed, 24 Jan 2007 16:37:00 -0000 From: Markus Deuling User-Agent: Thunderbird 1.5.0.9 (X11/20070102) MIME-Version: 1.0 To: GDB Patches Subject: [RFC] remote step over pthread_create()/dlopen() bug Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-01/txt/msg00501.txt.bz2 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