From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8492 invoked by alias); 8 Jun 2005 18:36:41 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 8468 invoked by uid 22791); 8 Jun 2005 18:36:39 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 08 Jun 2005 18:36:39 +0000 Received: from drow by nevyn.them.org with local (Exim 4.50) id 1Dg5Po-0007qw-8C; Wed, 08 Jun 2005 14:36:36 -0400 Date: Wed, 08 Jun 2005 18:36:00 -0000 From: Daniel Jacobowitz To: Kris Warkentin Cc: GDB Subject: Re: Linux ptrace handling of SIGSTOP Message-ID: <20050608183636.GA30101@nevyn.them.org> Mail-Followup-To: Kris Warkentin , GDB References: <42A73A48.1080002@qnx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42A73A48.1080002@qnx.com> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-06/txt/msg00072.txt.bz2 On Wed, Jun 08, 2005 at 02:34:48PM -0400, Kris Warkentin wrote: > The Linux documentation for ptrace(PTRACE_CONT, ...., signal) claims > that signal will be passed unless it is a SIGSTOP. I hit a process that > I was debugging with a SIGSTOP, gdb of course stops claiming that the > process got a SIGSTOP. I continue and gdb again says that the process > was hit with a SIGSTOP. If I continue a second time, the process > actually continues. > > I was debugging child_resume and observed that both times the ptrace was > being called with SIGSTOP but the second time the process actually > resumes. This implies to me that the ptrace documentation is not > completely correct because it seems that the first SIGSTOP is being > delivered. > > Am I missing something? The reason that I ask is that we're not > currently handling SIGSTOP properly in QNX so I'm trying to find out > what the expected behaviour should be. Based on the docs, I would have > thought that the continue would just cause it to resume without further > interruption. I don't know - you'd have to ask the kernel developers, i.e. I'm punting your question to Roland. -- Daniel Jacobowitz CodeSourcery, LLC