Isn't the real issue here that if kprobes attempts to put in a 'break
0x80200' into a B-slot that it instead becomes a 'break.b 0' -- as the
break.b does not accept an immediate value? Which probably means that
either kprobes (a) should not rely on the immediate value of the break
at all (always put in an immediate value of 0), or (b) kprobes should
not allow a probe on a B-slot of an instruction bundle.
Kprobes does have the two cases covered in traps.c (case 0 - when a
B-slot break is used, and case 0x80200 for a non-B-slot break). But this
doesn't seem very clean. (If it was decided that one should not overload
the break 0 case, and instead use a uniquely defined break number, then
it fails on a B-slot probe. If it is OK to overload the break 0 case,
why have another break number at all?)
I started doing a port of kprobes, ran into this, and decided to try a
different mechanism that replaced the whole instruction bundle - so that
I could format the instruction bundle to allow a break instruction with
an immediate value (and thus uniquely identify KPROBE breaks).
[Basically put the break in the 1st slot (all the time), and then go
execute the original instruction *bundle* elsewhere when the break is hit.]
PS. I don't see the 0x80300 defined __IA64_BREAK_JPROBE being used
anywhere...
Alan D. Brunelle
Hewlett-Packard
Lynch, Rusty wrote:
From: Keith Owens [mailto:[email protected]]
Anil S Keshavamurthy <[email protected]> wrote:
This patch adds the kdebug die notification mechanism needed by
Kprobes.
case 0: /* unknown error (used by GCC for
__builtin_abort()) */
+ if (notify_die(DIE_BREAK, "kprobe", regs, break_num,
TRAP_BRKPT, SIGTRAP)
+ == NOTIFY_STOP) {
+ return;
+ }
die_if_kernel("bugcheck!", regs, break_num);
sig = SIGILL; code = ILL_ILLOPC;
break;
Nit pick. Any break instruction in a B slot will set break_num 0, so
you cannot tell if the break was inserted by kprobe or by another
debugger. Setting the string to "kprobe" is misleading here, change it
to "break 0".
Good catch. We'll update the informational string.
--rusty
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]