This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc] catch syscall
- From: Alan Curry <pacman at TheWorld dot com>
- To: drow at false dot org (Daniel Jacobowitz)
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 6 Jul 2007 19:48:06 -0400 (EDT)
- Subject: Re: [rfc] catch syscall
Daniel Jacobowitz writes the following:
>
>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.
I've tried to make that happen and I can't.
>
>> 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.