From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6717 invoked by alias); 3 Jul 2007 17:52:01 -0000 Received: (qmail 6706 invoked by uid 22791); 3 Jul 2007 17:52: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; Tue, 03 Jul 2007 17:51:58 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 87D45982C3; Tue, 3 Jul 2007 17:51:56 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 5714C9829D; Tue, 3 Jul 2007 17:51:56 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1I5mX8-0004Qc-2A; Tue, 03 Jul 2007 13:51:26 -0400 Date: Tue, 03 Jul 2007 17:52:00 -0000 From: Daniel Jacobowitz To: Alan Curry Cc: gdb-patches@sourceware.org Subject: Re: [rfc] catch syscall Message-ID: <20070703175126.GJ2868@caradoc.them.org> Mail-Followup-To: Alan Curry , gdb-patches@sourceware.org References: <200706092017.l59KH3Rr2893350@shell01.TheWorld.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200706092017.l59KH3Rr2893350@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/msg00074.txt.bz2 On Sat, Jun 09, 2007 at 04:17:03PM -0400, Alan Curry wrote: > For a long time I've wanted to be able to mix strace-like syscall tracing > with the awesome power of gdb. Other people have mentioned the idea a few > times over the years, but nothing ever seems to get done. So I did something. Thank you! I've always wanted this. Every time I thought about it, I got hung up on all the argument decoding that strace knows how to do. But just because we don't know how to decode arguments doesn't mean this isn't useful anyway. For a patch of this size, we will need an FSF copyright assignment. Unless you or your employer have one in place already, you'll need to contact the FSF for this. Let me know if you need one, and I'll send you the request form. > 1. PTRACE_O_TRACESYSGOOD is enabled to make syscall stops distinguishable > from random SIGTRAPs > 2. When the inferior is resumed, if there is an enabled syscall catchpoint, > PTRACE_SYSCALL is used instead of PTRACE_CONT. > 3. When the inferior stops, the special signal value 0x80|SIGTRAP is > recognized and the syscall catchpoint claims responsibility for the > stop. 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. On a minor note, be careful about tabs please; our convention is to always use a tab in place of eight leading spaces, and I can tell from some parts of your diff that line up funny that you haven't. Well, either that our your mail client ate them... 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. There's already TARGET_WAITKIND_SYSCALL_ENTRY and TARGET_WAITKIND_SYSCALL_EXIT. Their default behavior is only useful for HP/UX, but maybe we could combine them with this new thing. It's a pity ttrace makes it easy to separate entry/exit and ptrace doesn't. > +#if 0 > + /* Ideally, print the syscall's __NR here, and maybe its name. > + Getting the __NR and mapping it to a name are both arch-specific > + so I'm saving it for later. It'll go something like this: */ > + if (b->syscall_name != NULL) > + { > + ui_out_field_string (uiout, "what", b->syscall_name); > + } > +#endif Yes, good choice to wait :-) If we want to do this later, we can add gdbarch methods as needed. > diff -ru gdb-6.6/gdb/inferior.h gdb-6.6/gdb/inferior.h > --- gdb-6.6/gdb/inferior.h 2006-10-18 11:56:13.000000000 -0500 > +++ gdb-6.6/gdb/inferior.h 2007-06-06 21:54:37.000000000 -0500 > @@ -417,6 +417,12 @@ > > extern int proceed_to_finish; > > +/* Nonzero if a syscall catchpoint is active. There must be a better place > + for this, where it can be associated with a particular process if multiple > + forks are being traced. Where should it be really? */ > + > +extern int catching_syscalls; > + > /* Save register contents here when about to pop a stack dummy frame, > if-and-only-if proceed_to_finish is set. > Thus this contains the return value from the called function (assuming I guess this is as good as anywhere. I don't see how to do it without the global while still reusing inf_ptrace_resume. > @@ -1497,6 +1507,33 @@ > } > goto process_event_stop_test; > > + case TARGET_WAITKIND_SYSCALL: > + if (debug_infrun) > + fprintf_unfiltered (gdb_stdlog, "infrun: TARGET_WAITKIND_SYSCALL\n"); > + 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. > +/* Determine which PTRACE_O_* flags are usable with the running kernel. > > - First, we try to enable fork tracing on ORIGINAL_PID. If this fails, > + First, we try to enable TRACESYSGOOD on ORIGINAL_PID. If this fails, the > + kernel is too old to support any of the flags. > + > + Next, we try to enable fork tracing on ORIGINAL_PID. If this fails, > we know that the feature is not available. This may change the tracing > options for ORIGINAL_PID, but we'll be setting them shortly anyway. > This won't actually work, I don't think. Old kernels used to always allow TRACESYSGOOD or else silently ignore attempts to set it. I might be wrong though - you have to go back quite a ways to find a kernel where this doesn't work. Probably we can just assume TRACESYSGOOD works OK. > + catching_syscalls=0; Spaces around operators please. -- Daniel Jacobowitz CodeSourcery