From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19123 invoked by alias); 15 Aug 2008 20:28:11 -0000 Received: (qmail 19114 invoked by uid 22791); 15 Aug 2008 20:28:10 -0000 X-Spam-Check-By: sourceware.org Received: from s200aog13.obsmtp.com (HELO s200aog13.obsmtp.com) (207.126.144.127) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 15 Aug 2008 20:27:18 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob013.postini.com ([207.126.147.11]) with SMTP; Fri, 15 Aug 2008 20:27:15 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 26A19DA47 for ; Fri, 15 Aug 2008 20:27:10 +0000 (GMT) Received: from mail1.bri.st.com (unknown [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id EBC024C7CA for ; Fri, 15 Aug 2008 20:27:09 +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 CKM60528 (AUTH antony); Fri, 15 Aug 2008 21:27:09 +0100 (BST) Message-ID: <48A5E69D.9050901@st.com> Date: Sat, 16 Aug 2008 15:12:00 -0000 From: Antony KING User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: gdb@sourceware.org Subject: Spurious SIGTRAP reported by GDB 6.8 when debugging embedded RTOS application Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00195.txt.bz2 Hi, I have just upgraded our variant of GDB to version 6.8 (from 6.7.1) and have noticed a new behaviour which I would like to "fix". Using the following debug session snapshot: > (gdb) tbreak mytaskfunc > Breakpoint 1 at > (gdb) continue > Hello from root; before task_create > Hello from root; after task_create > [New Thread 3] > [Switching to Thread 3] > mytaskfunc (p=0x0) at test.c:40 > 40 int i = (int)p; > (gdb) info thread > [New Thread 1] > [New Thread 2] > [New Thread 4] > [New Thread 5] > [New Thread 6] > [New Thread 7] > 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 > 1690 { > (gdb) step > > Program received signal SIGTRAP, Trace/breakpoint trap. > [Switching to Thread 3] > 0x880017a4 in mytaskfunc (p=0x0) at /vob/shbri-src-testsuites/regression-tests/gdb/INSbl23029.c:40 > 40 int i = (int)p; you can see that GDB is reporting a "SIGTRAP" message after switching threads from "Thread 3" (the active thread) to "Thread 7" and then performing the step. GDB is expecting that on completion of the step the stopped thread reported by the target will be same as was selected by GDB before the step (e.g. "Thread 7"). This will not generally happen with our RTOS since it is not possible to change the currently running thread (as exhibited above). This report of "SIGTRAP" by GDB (and also the premature termination of the step) is not desirable as this tends to agitate our users :-). Is there a way I can modify our implementation of the target interface in GDB that will prevent this from occurring ? After examining the sources it looks like this situation is caused by the call to context_switch() (in infrun.c), which is resetting the global flag step_range_end (among others) and this is consequentially preventing handle_inferior_event() from recognising that a step is in progress. Is there a way avoiding this ? Alternative is it possible to undo the effect of the "thread 7" command so that GDB has the correct "current thread" context when resuming the target ? Cheers, Antony. [Note that our version of GDB is used to support the debugging of embedded SH-4 applications using our own RTOS with our own host/target interface hardware.]