[CRIU] [PATCH 2/3] dump: use breakpoints instead of tracing syscalls (v2)
Christopher Covington
cov at codeaurora.org
Fri Sep 19 07:57:44 PDT 2014
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.
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
More information about the CRIU
mailing list