From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24135 invoked by alias); 7 Jul 2007 00:51:01 -0000 Received: (qmail 24101 invoked by uid 22791); 7 Jul 2007 00:51:00 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 07 Jul 2007 00:50:54 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 28F53982D6; Sat, 7 Jul 2007 00:50:53 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 00509982A5; Sat, 7 Jul 2007 00:50:52 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1I6yVf-0003iJ-Ab; Fri, 06 Jul 2007 20:50:51 -0400 Date: Sat, 07 Jul 2007 00:51:00 -0000 From: Daniel Jacobowitz To: Alan Curry Cc: gdb-patches@sourceware.org Subject: Re: [rfc] catch syscall Message-ID: <20070707005051.GA14000@caradoc.them.org> Mail-Followup-To: Alan Curry , gdb-patches@sourceware.org References: <20070704220408.GA10362@caradoc.them.org> <200707062348.l66Nm63I461200@shell01.TheWorld.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707062348.l66Nm63I461200@shell01.TheWorld.com> User-Agent: Mutt/1.5.15 (2007-04-09) X-IsSubscribed: yes 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/msg00125.txt.bz2 On Fri, Jul 06, 2007 at 07:48:06PM -0400, Alan Curry wrote: > >> 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. I don't know. The best answer may be to not use the generic routine any more. There is not much of one, and some of it (the ptid check) is not required with the linux-nat usage. -- Daniel Jacobowitz CodeSourcery