This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Questions about kprobes implementation on SMP and preemptible kernels


On Tue, Jan 16, 2007 at 11:09:55AM +0530, Ananth N Mavinakayanahalli wrote:
> On Mon, Jan 15, 2007 at 09:48:26PM -0600, Quentin Barnes wrote:
> > Q #3:
> > The ARM kprobes model uses an undefined instruction for its
> > kprobe.  This is necessary since ARM's breakpoint instruction (BKPT)
> > triggers entry into the same CPU service mode as the kernel runs
> > in.  On ARM, this is bad to do.  No problem though since undefined
> > instructions have their own mode.  Due to this, kprobe_handler() is
> > called from ARM's undefined instruction handler, do_undefinstr().
> 
> AFAIK, s390 also uses such a trick (using an undefined instruction).

Yes, s390 uses an undefined opcode. I basically followed the same
"trick" gdb uses to set a breakpoint. I know little about arm, but on
the other architectures I've done dprobes work for (power, ia64) the
criteria for choosing the breakpoint instruction was "something that
will get the system into kernel mode". I tried for a while on s390 to
use real opcodes for the breakpoint instruction, s390 doesn't really
have a native equivalent of the Intel int3. The architecture does have
variable length instructions, so the ones that would work well were
inevitably too long. In the end going back to the tried and true invalid
op worked fine.

Thanks
Mike

-----------------------------------------
Michael Grundy - grundym@us.ibm.com
Money and widgets need managers, people need leaders.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]