This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: Hitachi djprobe mechanism
- From: Karim Yaghmour <karim at opersys dot com>
- To: Roland McGrath <roland at redhat dot com>
- Cc: "Keshavamurthy, Anil S" <anil dot s dot keshavamurthy at intel dot com>, Mathieu Desnoyers <compudj at krystal dot dyndns dot org>, Andi Kleen <ak at suse dot de>, Masami Hiramatsu <masami dot hiramatsu at gmail dot com>, Masami Hiramatsu <hiramatu at sdl dot hitachi dot co dot jp>, Richard J Moore <richardj_moore at uk dot ibm dot com>, systemtap at sources dot redhat dot com, sugita at sdl dot hitachi dot co dot jp, Satoshi Oshima <soshima at redhat dot com>, michel dot dagenais at polymtl dot ca
- Date: Mon, 01 Aug 2005 23:46:02 -0400
- Subject: Re: Hitachi djprobe mechanism
- Organization: Opersys inc.
- References: <20050802032137.DE2E5180EC3@magilla.sf.frob.com>
- Reply-to: karim at opersys dot com
Roland McGrath wrote:
> At this point, you know that no CPU's PC can get into the probe-insertion
> area without hitting the int3. There is no danger of "half baked"
> instruction decoding because any CPU getting there hits the breakpoint and
> enters an explicit synchronization path through kprobes infrastructure code.
> A CPU that hits this breakpoint can either wait for the probe inserter to
> finish, or it could just handle it in kprobes style and move on if the
> instruction following the one copied by kprobes is outside the mutation area.
>
> You store the remaining bytes of the probe jmp instruction. Then store the
> first byte, replacing the int3. Then let any synchronized CPUs continue;
> they could either resume kprobe-style processing, or back up the PC and
> restart to allow the new probe-inserted jmp to happen.
Possibly works if you're operating on instructions of 5 bytes or more only.
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546