From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23420 invoked by alias); 18 Aug 2008 18:30:22 -0000 Received: (qmail 23403 invoked by uid 22791); 18 Aug 2008 18:30:20 -0000 X-Spam-Check-By: sourceware.org Received: from s200aog11.obsmtp.com (HELO s200aog11.obsmtp.com) (207.126.144.125) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Aug 2008 18:29:36 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob011.postini.com ([207.126.147.11]) with SMTP; Mon, 18 Aug 2008 18:25:10 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 3ABDBDA41; Mon, 18 Aug 2008 18:25:06 +0000 (GMT) Received: from mail1.bri.st.com (unknown [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id D439B4C7F5; Mon, 18 Aug 2008 18:25:05 +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 CKM70308 (AUTH antony); Mon, 18 Aug 2008 19:25:05 +0100 (BST) Message-ID: <48A9BE80.9080306@st.com> Date: Wed, 20 Aug 2008 01:31: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, Daniel Jacobowitz , Ulrich Weigand Subject: Re: Spurious SIGTRAP reported by GDB 6.8 when debugging embedded RTOS application References: <200808152315.m7FNFeMU025871@d12av02.megacenter.de.ibm.com> <48A94CE7.8010400@st.com> <20080818124205.GA6958@caradoc.them.org> <200808181416.47444.pedro@codesourcery.com> In-Reply-To: <200808181416.47444.pedro@codesourcery.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/msg00222.txt.bz2 This change in behaviour looks like it has occurred as a result of some structural changes in infrun.c. After a quick scan I can see numerous (related I think) changes which are possible candidates for this behavioural change, and all in the area of single stepping :-). It looks like that these changes have been made in order to improve the expected behaviour of GDB when debugging multi-threaded applications; unfortunately while this is OK for debugging user processes on OS's such as Linux it does not fit nicely onto my RTOS :-(. I suspect that your explanation about the behaviour of "next" when the target stopped due to a breakpoint may be implicated in this change :-). I do not know what the "right" solution in general is, but for my RTOS I think the only recourse is to ensure that the last stopped thread is selected before performing a step operation. Cheers, Antony. Pedro Alves wrote: > On Monday 18 August 2008 13:42:05, Daniel Jacobowitz wrote: >> On Mon, Aug 18, 2008 at 11:20:23AM +0100, Antony KING wrote: >>> 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. > > What is confusing me a bit, is that you claim that this is a new > behaviour in 6.8, coming from 6.7.1. What was it that changed between > 6.7.1 and 6.8? That is, why did it work in 6.7.1 ? > > Note that if the user switches threads when stopped at a breakpoint, and > the user issues "next", gdb will first revert back to the thread that > hit the breakpoint originally, do a single-step to get over the breakpoint, > and then when that finishes, reverts back to the new thread the user had > selected, to proceed with the "next" command.