From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7155 invoked by alias); 18 Aug 2008 10:21:42 -0000 Received: (qmail 7146 invoked by uid 22791); 18 Aug 2008 10:21:40 -0000 X-Spam-Check-By: sourceware.org Received: from s200aog14.obsmtp.com (HELO s200aog14.obsmtp.com) (207.126.144.128) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Aug 2008 10:20:56 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob014.postini.com ([207.126.147.11]) with SMTP; Mon, 18 Aug 2008 10:20:24 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 35397DA45; Mon, 18 Aug 2008 10:20:24 +0000 (GMT) Received: from mail1.bri.st.com (unknown [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id E1E2E4C425; Mon, 18 Aug 2008 10:20:23 +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 CKM66541 (AUTH antony); Mon, 18 Aug 2008 11:20:23 +0100 (BST) Message-ID: <48A94CE7.8010400@st.com> Date: Mon, 18 Aug 2008 18:16:00 -0000 From: Antony KING User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ulrich Weigand Cc: gdb@sourceware.org Subject: Re: Spurious SIGTRAP reported by GDB 6.8 when debugging embedded RTOS application References: <200808152315.m7FNFeMU025871@d12av02.megacenter.de.ibm.com> In-Reply-To: <200808152315.m7FNFeMU025871@d12av02.megacenter.de.ibm.com> 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/msg00216.txt.bz2 Thanks for the explanation. Unfortunately GDB has no influence over the RTOS, it is merely an observer. This means that it cannot change the status of threads or decide which thread is to execute; this is solely under the control of the RTOS. Your suggestion of disabling H/W single stepping is interesting but unfortunately will not be suitable as we need the efficiency of the H/W single step to ensure a responsive debug experience (especially under Eclipse). I think I might investigate the strategy of modifying GDB so that it restores the currently selected thread back to the current running thread when performing a step (or maybe generating an error). Cheers, Antony. Ulrich Weigand wrote: > Antony KING wrote: > >> 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). > > Here's my understanding of this issue: GDB does not actually care about > the "currently running" thread -- this is up the OS scheduler which GDB > cannot and does not attempt to influence. > > GDB does cares about the following two properties of threads: > > - Which threads are *runnable* (i.e. not stopped) > > GDB may -depending on the situation- want to tell the target to mark > all threads runnable, no thread runnable, or just a single thread > runnable. (If it marks all threads runnable, it is of course up to > the OS which threads it schedules in which order to actually *run* > on any of the physical processors.) > > - Which thread to run in hardware single-step mode > > On targets that support hardware single-step, GDB will want to decide > *which* of the threads the single-step mode should be applied to. > (GDB will only ever mark one thread for single-stepping.) > > > It seems that you're running into problems with the second point: > GDB has asked the target to hardware single-step thread 7, but your OS > actually enabled hardware single-stepping for thread 3. > > If possible, you should fix this in your target implementation. If > this is not possible for your RTOS, one simple way to solve the issue > might be to tell the GDB core that your target does not support hardware > single-stepping. Then, GDB will fall back to software single-stepping, > where it cares for stepping the correct thread by itself. > > Bye, > Ulrich