[CRIU] [PATCH 2/3] dump: use breakpoints instead of tracing syscalls (v2)

[Andrew Vagin]

On Fri, Sep 19, 2014 at 10:57:44AM -0400, Christopher Covington wrote:
> On 09/19/2014 10:45 AM, Pavel Emelyanov wrote:
> > On 09/19/2014 06:19 PM, Christopher Covington wrote:
> >> On 09/19/2014 10:01 AM, Pavel Emelyanov wrote:
> >>> On 09/17/2014 07:12 PM, Andrey Vagin wrote:
> >>>> Currently CRIU traces syscalls to catch a moment, when sigreturn() is
> >>>> called. Now we trace recv(cmd), close(logfd), close(cmdfd), sigreturn().
> >>>>
> >>>> We can reduce a number of steps by using hw breakpoints. A breakpoint is
> >>>> set before sigreturn, so we will need to trace only it.
> >>>>
> >>>> v2: In the first version a breakpoint is set after sigreturn. In this
> >>>> case we have a problem with signals. If a process has pending signals,
> >>>> it will start to precess them after exiting from sigreturn(), but before
> >>>> returning to userspace. So the breakpoint will not be triggered.
> >>>>
> >>>> And at the end Here are a few numbers how we catch sigreturn.
> >>>> Before this patch criu executes 36 syscalls and gets 12 signals.
> >>>> With this patch criu executes 18 syscalls and gets 5 signals.
> >>>>
> >>>> Signed-off-by: Andrey Vagin <avagin at openvz.org>
> >>>
> >>> OK, applied, thanks a lot :)
> >>>
> >>> Christopher, if it's possible, could you help us placing breakpoints
> >>> into ARM parasite and restorer? :) This is quite good optimization,
> >>> I think it makes sense to have one on ARM too.
> >>
> >> I will look into this. 
> > 
> > Great! Thanks :)
> > 
> >> Some Linux interfaces that I've used in the past that
> >> may be available across architectures are:
> >>
> >> Software breakpoint placement with uprobes. This requires debugfs.
> >>
> >> https://lwn.net/Articles/499190/
> >>
> >> Hardware breakpoint placement with perf_event_open.
> >>
> >> https://github.com/deater/perf_event_tests/blob/master/tests/breakpoints/breakpoint_support.c
> >>
> >> http://man7.org/linux/man-pages/man2/perf_event_open.2.html
> > 
> > Don't you know which of them are used by gdb? AFAIK the ones for x86
> > were taken from there.
> 
> The rumor I've heard is that GDB doesn't use any Linux-specific interfaces
> because they want implementations they can use across Linux, BSD, and Hurd.

Hi Christopher,

I took a part of my code from gdb.

Look at this file
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/arm-linux-nat.c;hb=HEAD

Thanks,
Andrew

> 
> Christopher
> 
> -- 
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by the Linux Foundation.