Re: [rfc] catch syscall

[Daniel Jacobowitz <drow at false dot org>]

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