From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4838 invoked by alias); 26 Aug 2008 19:17:47 -0000 Received: (qmail 3038 invoked by uid 22791); 26 Aug 2008 19:16:05 -0000 Received: from s200aog11.obsmtp.com (HELO s200aog11.obsmtp.com) (207.126.144.125) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 26 Aug 2008 19:13:22 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob011.postini.com ([207.126.147.11]) with SMTP; Tue, 26 Aug 2008 19:11:20 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 E823ADA46; Tue, 26 Aug 2008 19:11:19 +0000 (GMT) Received: from mail1.bri.st.com (unknown [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 9F56F4C520; Tue, 26 Aug 2008 19:11:19 +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 CKN16153 (AUTH antony); Tue, 26 Aug 2008 20:11:19 +0100 (BST) Message-ID: <48B45556.2030406@st.com> Date: Wed, 27 Aug 2008 21:38:00 -0000 From: Antony KING User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Ulrich Weigand Cc: Pedro Alves , gdb@sourceware.org Subject: Re: Spurious SIGTRAP reported by GDB 6.8 when debugging embedded RTOS application References: <200808221441.m7MEflLR027889@d12av02.megacenter.de.ibm.com> In-Reply-To: <200808221441.m7MEflLR027889@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/msg00279.txt.bz2 Thanks for the additional information on the execution logic of GDB and the patch reference. This extra information will ensure I do not do the "wrong thing" in my implementation of target_resume when I add the checks that are currently missing :-). Cheers, Antony. Ulrich Weigand wrote: > Anthony King wrote: > >> 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 :-) ? > > Hmmm. The meaning of to_has_thread_control doesn't seem to be completely > well defined. I had thought it refered to whether the target allows to > selectively resume just one thread versus resuming all threads. > > Under this interpretation, if to_has_thread_control is tc_none, the > target's resume method should always be called with ptid == minus_one_ptid. > > However, in actual fact infrun.c attempts to resume a single thread > unconditionally in the following situations: > > - when single-stepping past a software single-step breakpoint > > - when single-stepping past a breakpoint > > - when stepping past a syscall-return event > > - when stepping over a steppable/nonsteppable watchpoint > > - when in non-stop mode > > Some of these can be avoided by choices the target can make (e.g. > to support hardware single-stepping, and to not support non-stop > mode). For others, there doesn't seem to be a way to avoid them. > This looks like long-standing behaviour, however ... > > In addition, even when calling the target's resume function with > ptid == minus_one_ptid, GDB will still expect to be able to choose > which of the resumed threads goes into single-step mode. > >> 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). > > The change in behaviour is caused by my patch: > http://sourceware.org/ml/gdb-patches/2007-07/msg00278.html > This fixed the previous behaviour where "step" would always implicitly > switch back to the last thread that stopped. > > Bye, > Ulrich