From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12911 invoked by alias); 18 Aug 2008 18:16:18 -0000 Received: (qmail 12901 invoked by uid 22791); 18 Aug 2008 18:16:17 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate3.de.ibm.com (HELO mtagate3.de.ibm.com) (195.212.29.152) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Aug 2008 18:15:29 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id m7IIFOBB179704 for ; Mon, 18 Aug 2008 18:15:24 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m7IIFOud2400436 for ; Mon, 18 Aug 2008 20:15:24 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m7IIFOu2006644 for ; Mon, 18 Aug 2008 20:15:24 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id m7IIFNSo006641; Mon, 18 Aug 2008 20:15:23 +0200 Message-Id: <200808181815.m7IIFNSo006641@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 18 Aug 2008 20:15:23 +0200 Subject: Re: Spurious SIGTRAP reported by GDB 6.8 when debugging embedded RTOS application To: antony.king@st.com (Antony KING) Date: Tue, 19 Aug 2008 00:33:00 -0000 From: "Ulrich Weigand" Cc: gdb@sourceware.org In-Reply-To: <48A9B65A.1020307@st.com> from "Antony KING" at Aug 18, 2008 06:50:18 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg00221.txt.bz2 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 -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com