From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22378 invoked by alias); 18 Aug 2008 13:16:45 -0000 Received: (qmail 22367 invoked by uid 22791); 18 Aug 2008 13:16:44 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Aug 2008 13:16:10 +0000 Received: (qmail 312 invoked from network); 18 Aug 2008 13:16:08 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Aug 2008 13:16:08 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: Spurious SIGTRAP reported by GDB 6.8 when debugging embedded =?iso-8859-1?q?=09RTOS_?= application Date: Mon, 18 Aug 2008 18:36:00 -0000 User-Agent: KMail/1.9.9 Cc: Daniel Jacobowitz , Antony KING , Ulrich Weigand References: <200808152315.m7FNFeMU025871@d12av02.megacenter.de.ibm.com> <48A94CE7.8010400@st.com> <20080818124205.GA6958@caradoc.them.org> In-Reply-To: <20080818124205.GA6958@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808181416.47444.pedro@codesourcery.com> 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/msg00218.txt.bz2 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. -- Pedro Alves