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, all non-kprobe breakpoints are left to the kernel to be handled. > The objective here is to intercept the trap handling of a certain > category of such breakpoints and emit a warning. The premise being > that .kprobes.text section is a logical breakpoint-free zone.
Oh, I think I've gotten what misleads you. The .kprobes.text section is a KPROBES-FREE zone. There may be breakpoints owned by other debuggers and hand-coded breakpoints (like as jprobe_return). >> Please consider that someone expands jprobe(jprobe2) which uses >> jprobe_return2() instead of jprobe_return(), how would you handle it? > > By a simple modification of is_jprobe_bkpt() (defined in patch #2 of > this series). IMO, one of advantages of current logic is that you can add another break_handler-based probe as an module without any patches. Even if someone makes fooprobe which is not a jprobe variant, current logic can treat it correctly. (Another advantage is the performance. Current logic checks only if there is a running kprobe and there is no kprobes related to the trapped address, instead of checking address section every time when each breakpoint is hit.) >> Current kprobes provides an opportunity to those external probe frameworks >> for checking it by themselves. > > Could you clarirfy this with some example. For now I'm assuming that > by external probe frameworks you mean kernel modules using kprobes. Yes, I mentioned it above. > If > they embed breakpoints in their handlers, then they will simply not be > caught by this check because thay cannot lie in the .kprobes.text > section. They cannot lie kprobes in the .kprobes.text section, but can put breakpoints by hand. this is the reason why kprobes provides break_handler. Thanks, Best Regards, -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division e-mail: [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
