From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26381 invoked by alias); 18 Aug 2008 18:36:01 -0000 Received: (qmail 26369 invoked by uid 22791); 18 Aug 2008 18:36:01 -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:34:47 +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:33:35 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 65D4BDA6A; Mon, 18 Aug 2008 18:33:35 +0000 (GMT) Received: from mail1.bri.st.com (unknown [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 1CF814C7FC; Mon, 18 Aug 2008 18:33:35 +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 CKM70329 (AUTH antony); Mon, 18 Aug 2008 19:33:34 +0100 (BST) Message-ID: <48A9C07E.2050504@st.com> Date: Wed, 20 Aug 2008 14:30: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: <200808181815.m7IIFNSo006641@d12av02.megacenter.de.ibm.com> In-Reply-To: <200808181815.m7IIFNSo006641@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/msg00223.txt.bz2 Thanks for the definition. I had not fully grasped this aspect of the target_resume interface. For my target interface only mode (1) can be properly supported. Modes (2) and (4) cannot be supported at all and mode (3) can only be supported by ensuring that inferior_ptid is set to the last stopped thread before commencing stepping. [Actually mode (4) can be supported but only if ptid == last stopped thread, but this is the similar to supporting mode (3).] Cheers, Antony. Ulrich Weigand wrote: > Anthony King wrote: > >> I have checked the implementation and GDB is calling my target_resume >> with a ptid of -1 (resume all threads), which I believe is the expected >> argument (since scheduler locking is not supported). However I think I >> will add an error check in my target_resume just in case GDB requests a >> single thread to be resumed. > > Note that even if target_resume is called with a ptid of -1 to resume > all threads, if the "step" flag is on, GDB will still expect that just > one thread receives the single-step flag. This thread is implictly > identified by the current value of the inferior_ptid global variable. > > So basically target_resume is supposed to provide these modes: > > (1) ptid == -1 -- step == 0 > resume all threads, no hardware single-step > (2) ptid != -1 -- step == 0 > resume only selected thread, no hardware single-step > (3) ptid == -1 -- step == 1 > resume all threads, hardware single-step inferior_ptid thread > (4) ptid != -1 -- step == 1 > resume only selected thread, hardware single-step that thread > > Bye, > Ulrich