This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v3 2/2] Implement 'catch syscall' for gdbserver
- From: Pedro Alves <palves at redhat dot com>
- To: Josh Stone <jistone at redhat dot com>, gdb-patches at sourceware dot org
- Cc: philippe dot waroquiers at skynet dot be, sergiodj at redhat dot com, eliz at gnu dot org, xdje42 at gmail dot com
- Date: Tue, 08 Dec 2015 13:31:24 +0000
- Subject: Re: [PATCH v3 2/2] Implement 'catch syscall' for gdbserver
- Authentication-results: sourceware.org; auth=none
- References: <1448506425-24691-1-git-send-email-jistone at redhat dot com> <1449196006-13759-1-git-send-email-jistone at redhat dot com> <1449196006-13759-2-git-send-email-jistone at redhat dot com> <5661929E dot 7020406 at redhat dot com> <566248F2 dot 5020908 at redhat dot com>
On 12/05/2015 02:16 AM, Josh Stone wrote:
> On a total tangent, is it ever possible that GDB/GDBserver might try to
> read and modify registers from a PTRACE_EVENT stop?
Do "catch fork", and you'll be given a prompt right inside a
PTRACE_EVENT_FORK, where you can try to poke at registers at will.
> If so, you should
> beware that registers may actually be in flux. I ran into this with
> Dyninst, which I fixed here[1] though I can't find the discussion now.
>
Ouch.
> The gist was that in a PTRACE_EVENT, the kernel may not have written the
> return register yet. Dyninst wanted to save registers, resume in a bit
> of instrumentation code, then restore registers and resume the normal
> program. So the saved registers got an intermediate RAX, and when it
> resumed into instrumentation the kernel finally wrote the good RAX
> return value to complete the syscall (which the instrumentation
> ignored). Then when dyninst restored registers the bad RAX was written
> back, and thus the normal program code didn't get the correct value for
> its fork return. My solution was to step out of the event with
> PTRACE_SYSCALL before doing anything else.
>
> [1]
> http://git.dyninst.org/?p=dyninst.git;a=commit;h=b89ea1d19677fa0dd9c605ef492c5f6dabf15752
Just to be clear, doesn't $orig_rax help here? Are you saving/restoring that?
Otherwise, it sounds like trying to run an inferior function
call [(gdb) p foo_func()] when the program is stopped for "catch fork"
may misbehave too.
Thanks,
Pedro Alves