From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30283 invoked by alias); 6 Jul 2007 23:48:19 -0000 Received: (qmail 30275 invoked by uid 22791); 6 Jul 2007 23:48:19 -0000 X-Spam-Check-By: sourceware.org Received: from pcls4.std.com (HELO TheWorld.com) (192.74.137.84) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 06 Jul 2007 23:48:14 +0000 Received: from shell.TheWorld.com (root@shell01.TheWorld.com [192.74.137.71]) by TheWorld.com (8.13.6/8.13.6) with ESMTP id l66Nm6db010754; Fri, 6 Jul 2007 19:48:09 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id l66Nm6J1463005; Fri, 6 Jul 2007 19:48:06 -0400 (EDT) Received: (from pacman@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id l66Nm63I461200; Fri, 6 Jul 2007 19:48:06 -0400 (EDT) From: Alan Curry Message-Id: <200707062348.l66Nm63I461200@shell01.TheWorld.com> Subject: Re: [rfc] catch syscall To: drow@false.org (Daniel Jacobowitz) Date: Fri, 06 Jul 2007 23:48:00 -0000 Cc: gdb-patches@sourceware.org In-Reply-To: <20070704220408.GA10362@caradoc.them.org> from "Daniel Jacobowitz" at Jul 04, 2007 06:04:08 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-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-07/txt/msg00124.txt.bz2 Daniel Jacobowitz writes the following: > >If you didn't use PTRACE_SYSCALL previously, are you always past the >point of syscall tracing by the time the process stops? I was worried >that the first PTRACE_SYSCALL might sometimes take you to an exit >rather than an entrance. But maybe that never happens. I've tried to make that happen and I can't. > >> We just need to keep track of a single bit of extra state for each inferior >> thread, to know what type of syscall event is expected next. I'm just having >> a hard time finding where per-inferior-thread information is supposed to be >> stored. > >This would probably be Linux-specific data, at least for now. Take a >look at the LWP list in linux-nat.c. If we want the generic code in inf-ptrace.c to behave differently (for example using PTRACE_SYSCALL instead of PTRACE_SINGLESTEP) depending on the value of a flag in that Linux-specific data, how do we get at it? Add another target method to return the flag? I noticed when doing this patch that adding a target method involves changing code in several different places.