From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13035 invoked by alias); 4 Jul 2007 22:04:15 -0000 Received: (qmail 13027 invoked by uid 22791); 4 Jul 2007 22:04:14 -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; Wed, 04 Jul 2007 22:04:11 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 293ED982C4; Wed, 4 Jul 2007 22:04:10 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id EEF109817A; Wed, 4 Jul 2007 22:04:09 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1I6CxE-0002m1-6b; Wed, 04 Jul 2007 18:04:08 -0400 Date: Wed, 04 Jul 2007 22:04:00 -0000 From: Daniel Jacobowitz To: Alan Curry Cc: gdb-patches@sourceware.org Subject: Re: [rfc] catch syscall Message-ID: <20070704220408.GA10362@caradoc.them.org> Mail-Followup-To: Alan Curry , gdb-patches@sourceware.org References: <20070703175126.GJ2868@caradoc.them.org> <200707042053.l64KrxOQ300954@shell01.TheWorld.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707042053.l64KrxOQ300954@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/msg00100.txt.bz2 On Wed, Jul 04, 2007 at 04:53:58PM -0400, Alan Curry wrote: > Just when I had given up on getting any replies... Sorry. GDB development does move slowly sometimes. > A lot of syscalls can be printed nicely using existing gdb commands, like > this: Right. Or, we could eventually build up a library in either C or Python to handle it. > >Sounds right to me. If we can distinguish between entry and exit, it > >would be nice to do so; though as I recall from hacking on strace, > >this is tricky. > > Actually it doesn't look too difficult in theory. As far as I can tell, a > syscall event is an exit if and only if the previous event was a syscall > entry and the program was continued with PTRACE_SYSCALL. (Interesting note > from my tests: if you're currently stopped at a syscall entry, stepi actually > steps further than cont. The PTRACE_SINGLESTEP completes the syscall and then > executes one userspace instruction, whereas cont maps to PTRACE_SYSCALL which > just finishes the syscall. This could be hacked around if it's a problem.) We'd probably want to use PTRACE_SYSCALL for single step, if we knew we were inside a syscall. 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. > 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. > >I don't realy like the duplication in breakpoint.c. I don't see a > >great way around it, either. Maybe there should be a single > >target_insert_catchpoint method. > > Well, I think I only added one of what there were already several of... Yeah. A lot of bits of GDB just accreted the way they are. This also applies to your question about the ptid_t argument; it's no longer useful. > >> + stop_signal = TARGET_SIGNAL_TRAP; > >> + pending_follow.kind = ecs->ws.kind; > > > >I don't think you need to mess with pending_follow. It's an event; > >_LOADED may be a better model than _FORKED for the event handling > >side. > > That was pure cut-and-paste. I haven't figured out what rules apply to the > use of pending_follow. Maybe it's the right place for that new > "next_syscall_event_will_be_exit" flag I was talking about. Maybe, but I don't think you'll need it. We can handle this entirely within the GNU/Linux specific support. > I did go back and look at those old kernels. PTRACE_SETOPTIONS didn't exist > before TRACESYSGOOD, so it looks like you should get an EIO for invalid > ptrace command. The ignoring of unrecognized options only applies to the > kernels new enough to have PTRACE_SETOPTIONS (and therefore at least > TRACESYSGOOD). But I didn't actually try compiling and booting one of those > old kernels to confirm it. Maybe we can skip some of the checking code, then. -- Daniel Jacobowitz CodeSourcery