Hi,
Abhishek Sagar wrote:
> On 1/28/08, Masami Hiramatsu <[EMAIL PROTECTED]> wrote:
>> Thank you for explanation, I hope I can understand it.
>> Even if it causes a trap recursively, it could be checked (and ignored) by
>> longjump_break_handler(), and passed to the debugger correctly.
>
> Yes, a
On 1/28/08, Masami Hiramatsu <[EMAIL PROTECTED]> wrote:
> Thank you for explanation, I hope I can understand it.
> Even if it causes a trap recursively, it could be checked (and ignored) by
> longjump_break_handler(), and passed to the debugger correctly.
Yes, all non-kprobe breakpoints are left t
Hi Abhishek,
Abhishek Sagar wrote:
> On 1/27/08, Masami Hiramatsu <[EMAIL PROTECTED]> wrote:
>> Sorry, I can not understand what issue these patches can solve.
>> The breakpoint which is inserted by external debugger will be checked by
>> kprobe_handler() and be passed to other exception_notify_ha
On 1/27/08, Masami Hiramatsu <[EMAIL PROTECTED]> wrote:
> Sorry, I can not understand what issue these patches can solve.
> The breakpoint which is inserted by external debugger will be checked by
> kprobe_handler() and be passed to other exception_notify_handlers.
> In that case, we don't need to
Hi Abhishek,
Abhishek Sagar wrote:
> Identify breakpoints in .kprobes.text section. These certainly aren't kprobe
> traps. However, we make an exception for the breakpoint hardcoded into
> jprobe_return.
Sorry, I can not understand what issue these patches can solve.
The breakpoint which is ins
Identify breakpoints in .kprobes.text section. These certainly aren't kprobe
traps. However, we make an exception for the breakpoint hardcoded into
jprobe_return.
Signed-off-by: Abhishek Sagar <[EMAIL PROTECTED]>
---
diff --git a/arch/x86/kernel/kprobes.c b/arch/x86/kernel/kprobes.c
index 45f29
6 matches
Mail list logo