Re: [patch 2/2] Displaced stepping across fork/vfork : test case

[Pedro Alves <pedro@codesourcery.com>]

On Wednesday 14 September 2011 12:09:50, Yao Qi wrote:
> > Very recent kernels will allow choosing the syscall instruction
> > in the vsyscall page.  It'll be better to make the test
> > skip on !x86-linux at the top, and then, change the test
> > to look for all alternatives of the syscall insn.
> >
> 
> I read some pages on vsyscall, and thought we can fetch the value of 
> AT_SYSINFO in auxv to get the address of __kernel_vsyscall.  However, 
> another simpler way comes up in my mind is to set possible syscall insn 
> to $syscall_insn like this,
> 
>    set syscall_insn "(int|syscall|sysenter)"
> 
> If we match either of them in instruction stream, we are sure program 
> will enter to syscall, so we don't have to worry about vsyscall page.

Yes, exactly what I meant.  Thanks.



> +       "continue to marker ($syscall)"
> +}

> +disp_step_cross_syscall "fork"
> +disp_step_cross_syscall "vfork"

There may be some fail/passes done from within gdb.exp procedures that
won't get that $syscall diferenciator, thus we can end up with
more than one UNTESTED/FAIL/PASS with the same message on gdb.sum/gdb.log.
It'd be better to use $pf_prefix instead (grep for uses in the testsuite).



We need to do something for systems that can't set a breakpoint in
the vsyscall page though (mine can't).  The test is surely failing there.



In the vfork test:

> +      global = 1;

Is the variable used for anything?


Otherwise, this looks okay to me.

-- 
Pedro Alves