From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5281 invoked by alias); 30 Aug 2011 22:03:28 -0000 Received: (qmail 5266 invoked by uid 22791); 30 Aug 2011 22:03:25 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from mail-fx0-f41.google.com (HELO mail-fx0-f41.google.com) (209.85.161.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 30 Aug 2011 22:03:04 +0000 Received: by fxg9 with SMTP id 9so146577fxg.0 for ; Tue, 30 Aug 2011 15:03:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.57.12 with SMTP id a12mr5899146fah.97.1314741782745; Tue, 30 Aug 2011 15:03:02 -0700 (PDT) Received: by 10.223.118.144 with HTTP; Tue, 30 Aug 2011 15:03:02 -0700 (PDT) Date: Tue, 30 Aug 2011 22:03:00 -0000 Message-ID: Subject: Thread Specific Breakpoints in Remote Targets From: Josh Watt To: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-08/txt/msg00131.txt.bz2 Hello, I'm working on implementing an GDB remote stub for a project, and I had a question about the behavior of GDB. For starters, I'm running GDB 7.3a compiled from vanilla source using MinGW on Windows XP with the following configure options: --target=3Darm-eabi The target device runs a custom RTOS, and I was able to get the remote stub to correctly report the OS threads back to GDB, thus allowing GDB to examine the individual threads. My question in particular is related to Thread Specific breakpoints. Our remote stub has the ability to internally implement thread specific breakpoints which saves a lot of overhead when the breakpoints are in frequently visited locations, since it means that we don't have to talk over the slow serial link to GDB just for it to tells us we can continue execution. However, it appears that GDB is doing some weird things with regard to the thread selection. See the log below: (gdb) info threads =A0 Id=A0=A0 Target Id=A0=A0=A0=A0=A0=A0=A0=A0 Frame =A0 41=A0=A0 Thread 1040 ("Thread 1040") at ... 40 Thread 1039 ("Thread 1039") at ... =A0 4=A0=A0=A0 Thread 1004 ("Thread 1004") at ... =A0 3=A0=A0=A0 Thread 1003 ("Thread 1003") at ... =A0 2=A0=A0=A0 Thread 1002 ("Thread 1002") at ... * 1=A0=A0=A0 Thread 1000 ("Thread 1000") at ... (gdb) break *$pc thread 1 Breakpoint 1 at 0x80232ce4: file ..., line 134. (gdb) set debug remote 1 (gdb) cont Continuing. Sending packet: $vCont?#49...Ack Packet received: Packet vCont (verbose-resume) is NOT supported Sending packet: $Hc3e8#7b...Ack Packet received: OK Sending packet: $s#73...Ack Packet received: T05thread:3e8;0:d05da48c;1:02000000;2:01000000;3:00000000;= 4:000 00000;5:00000000;6:00000000;7:00000000;8:00000000;9:00000000;A:00000000;B:0= 00000 00;C:00000000;D:00a9b782;E:69ec4080;F:e42c2380;19:3f000000; Sending packet: $Hg410#44...Ack Packet received: OK Sending packet: $g#67...Ack Packet received: 0000000000000000000000000000000001000000000000000000000000= 00000 00000000000000000000000000000000023280900086d6c87c1ef238068f04080 Sending packet: $Z0,80232ce2,2#0d...Ack Packet received: OK Sending packet: $Hg3e8#7f...Ack Packet received: OK Sending packet: $g#67...Ack Packet received: d05da48c02000000010000000000000000000000000000000000000000= 00000 0000000000000000000000000000000000000000000a9b78269ec4080e42c2380 Sending packet: $Hc0#db...Ack Packet received: OK Sending packet: $c#63...Ack Packet received: T05thread:3e8;0:e0302380;1:02000000;2:01000000;3:00000000;= 4:000 00000;5:00000000;6:00000000;7:00000000;8:00000000;9:00000000;A:00000000;B:0= 00000 00;C:00000000;D:00a9b782;E:69ec4080;F:e22c2380;19:3f000000; Sending packet: $Hg410#44...Ack Packet received: OK Sending packet: $g#67...Ack Packet received: 0000000000000000000000000000000001000000000000000000000000= 00000 00000000000000000000000000000000023280900086d6c87c1ef238068f04080 Sending packet: $z0,80232ce2,2#2d...Ack Packet received: OK Sending packet: $Hg3e8#7f...Ack Packet received: OK Sending packet: $g#67...Ack Packet received: e030238002000000010000000000000000000000000000000000000000= 00000 0000000000000000000000000000000000000000000a9b78269ec4080e22c2380 Breakpoint 1, Sending packet: $m80232ce2,4#c6...Ack Packet received: ff4803c8 0x80232ce2 in ... (gdb) As can been seen from the log, the stub is sending a message to switch to thread 1040 ($Hg410#44) right before setting the breakpoint (and again before deleting it). In subsequent operation, it is apparent that it is always switching to this thread when setting and clearing a breakpoint. Because of this, our remote stub cannot rely on the currently selected thread as the target thread for a given breakpoint and must communicate with GDB every time a breakpoint is hit. I also find it interesting that the selected thread is number 1040, which is the last thread reported to GDB by the remote stub. I looked through some of the code, and I think it is due to the following: In breakpoint.c there are calls to switch_to_program_space_and_thread() at lines 1895 and 2662 which must be selecting the wrong thread, but I'm not s= ure how to make it select the correct thread (if it is even supposed to). Thanks, -- ~JPEW