Re: [PATCH v3 2/2] Implement 'catch syscall' for gdbserver

[Pedro Alves <palves@redhat.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