From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16314 invoked by alias); 22 Aug 2008 14:43:01 -0000 Received: (qmail 15719 invoked by uid 22791); 22 Aug 2008 14:42:45 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate2.de.ibm.com (HELO mtagate2.de.ibm.com) (195.212.17.162) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 22 Aug 2008 14:41:54 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.1/8.13.1) with ESMTP id m7MFfQ2q011942 for ; Fri, 22 Aug 2008 15:41:26 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 m7MEfopr1954010 for ; Fri, 22 Aug 2008 16:41:50 +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 m7MEflDs027892 for ; Fri, 22 Aug 2008 16:41:47 +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 m7MEflLR027889; Fri, 22 Aug 2008 16:41:47 +0200 Message-Id: <200808221441.m7MEflLR027889@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Fri, 22 Aug 2008 16:41:47 +0200 Subject: Re: Spurious SIGTRAP reported by GDB 6.8 when debugging embedded RTOS application To: antony.king@st.com (Antony KING) Date: Fri, 22 Aug 2008 14:58:00 -0000 From: "Ulrich Weigand" Cc: pedro@codesourcery.com (Pedro Alves), gdb@sourceware.org In-Reply-To: <48AC6415.3000604@st.com> from "Antony KING" at Aug 20, 2008 07:36:05 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/msg00257.txt.bz2 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 -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com