From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 456 invoked by alias); 20 Aug 2008 18:37:37 -0000 Received: (qmail 446 invoked by uid 22791); 20 Aug 2008 18:37:36 -0000 X-Spam-Check-By: sourceware.org Received: from s200bog18.obsmtp.com (HELO s200bog18.obsmtp.com) (207.126.150.132) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 20 Aug 2008 18:36:52 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu2sys200bob018.postini.com ([207.126.147.11]) with SMTP; Wed, 20 Aug 2008 18:36:12 UTC Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id D4080DA63; Wed, 20 Aug 2008 18:36:07 +0000 (GMT) Received: from mail1.bri.st.com (unknown [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 209964C666; Wed, 20 Aug 2008 18:36:06 +0000 (GMT) Received: from [164.129.14.85] (bri1017.bri.st.com [164.129.14.85]) by mail1.bri.st.com (MOS 3.8.7a) with ESMTP id CKM85953 (AUTH antony); Wed, 20 Aug 2008 19:36:05 +0100 (BST) Message-ID: <48AC6415.3000604@st.com> Date: Thu, 21 Aug 2008 03:24:00 -0000 From: Antony KING User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Pedro Alves Cc: gdb@sourceware.org, Ulrich Weigand Subject: Re: Spurious SIGTRAP reported by GDB 6.8 when debugging embedded RTOS application References: <200808181815.m7IIFNSo006641@d12av02.megacenter.de.ibm.com> <48A9C07E.2050504@st.com> <200808181947.46104.pedro@codesourcery.com> In-Reply-To: <200808181947.46104.pedro@codesourcery.com> Content-Type: multipart/mixed; boundary="------------080207030807080108070809" X-IsSubscribed: yes 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: 2008-08/txt/msg00233.txt.bz2 This is a multi-part message in MIME format. --------------080207030807080108070809 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-length: 2533 The answer to your question is yes, this could be a strategy to implement what the user "expects". However I am not certain doing this in the stub/target side is the "right thing to do" since I do not think this problem is peculiar to my environment (plus it need to replicate some of the event handling that is already being performed by the main event handler of GDB). Looking at the implementation in infrun.c/infcmd.c, it seems, and I say this with caution :-), that with a certain amount of fettling the existing code to implement software stepping could be modified to support this scenario. I have yet to look into this as a possible solution since it looks like it could take a while to implement as I am not very familiar with this part of GDB. For the time being I think I will just report an error if the user attempts to step a thread which is not the last stopped thread (or automatically switch to the stopped thread before stepping) and put this on my to do list. Also, while I was trying to absorb the mechanics of GDB in this area, there seemed (to my untutored eye) an inconsistency between my target definition setting "to_has_thread_control" to "tc_none" and the execution model of infrun.c (esp. when it comes to stepping), or have I missed something :-) ? FYI I have attached the output of my test case when I use GDB 6.7.1 (with "set debug infrun 1"). As you can see there is no indication that a context switch has occurred by the step; it seems that in GDB 6.7.1 changing threads did not alter the thread to be stepped (i.e. the last stopped thread). Cheers, Antony. Pedro Alves wrote: > On Monday 18 August 2008 19:33:34, Antony KING wrote: >> Thanks for the definition. I had not fully grasped this aspect of the >> target_resume interface. For my target interface only mode (1) can be >> properly supported. Modes (2) and (4) cannot be supported at all and >> mode (3) can only be supported by ensuring that inferior_ptid is set to >> the last stopped thread before commencing stepping. >> >> [Actually mode (4) can be supported but only if ptid == last stopped >> thread, but this is the similar to supporting mode (3).] >> > > In your original example, would it work to put a special > "switch-thread breakpoint" at the PC of thread 7, so it forces > a thread switch on your target, and then continue hardware > single-stepping from there when it is hit? With care, > it seems this could be hidden entirelly on the stub/target side. > > (I'm still curious on how this worked on 6.7.1 though) --------------080207030807080108070809 Content-Type: text/plain; name="gdb671.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gdb671.log" Content-length: 2541 (gdb) set debug infrun 1 (gdb) tbreak mytaskfunc Breakpoint 1 at infrun: proceed (addr=0xffffffff, signal=144, step=0) (gdb) continue infrun: resume (step=0, signal=0) infrun: wait_for_inferior Hello from OS21 root; before task_create Hello from OS21 root; after task_create infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x880017a2 infrun: context switch infrun: Switching context from Thread 42000000 to Thread 3 infrun: BPSTAT_WHAT_STOP_NOISY infrun: stop_stepping [Switching to Thread 3] mytaskfunc (p=0x0) at 40 int i = (int)p; (gdb) info thread 7 Thread 7 ("My Task") 6 Thread 6 ("My Task") 5 Thread 5 ("My Task") 4 Thread 4 ("My Task") 3 Thread 2 ("Idle Task") 2 Thread 1 ("Root Task") * 1 Thread 3 ("My Task") (gdb) thread 7 [Switching to thread 7 (Thread 7)]#0 1691 { (gdb) info thread * 7 Thread 7 ("My Task") 6 Thread 6 ("My Task") 5 Thread 5 ("My Task") 4 Thread 4 ("My Task") 3 Thread 2 ("Idle Task") 2 Thread 1 ("Root Task") 1 Thread 3 ("My Task") infrun: proceed (addr=0xffffffff, signal=144, step=1) (gdb) step infrun: resume (step=1, signal=0) infrun: wait_for_inferior infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x880017a4 infrun: keep going infrun: resume (step=1, signal=0) infrun: prepare_to_wait infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x880017a6 infrun: stepping inside range [0x880017a2-0x880017ae] infrun: resume (step=1, signal=0) infrun: prepare_to_wait infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x880017a8 infrun: stepping inside range [0x880017a2-0x880017ae] infrun: resume (step=1, signal=0) infrun: prepare_to_wait infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x880017aa infrun: stepping inside range [0x880017a2-0x880017ae] infrun: resume (step=1, signal=0) infrun: prepare_to_wait infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x880017ac infrun: stepping inside range [0x880017a2-0x880017ae] infrun: resume (step=1, signal=0) infrun: prepare_to_wait infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x880017ae infrun: stepped to a different line infrun: stop_stepping mytaskfunc (p=0x0) at 41 printf("Hello from task %d\n", i); --------------080207030807080108070809--