This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfc] catch syscall


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]