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: "Keshavamurthy, Anil S" <anil dot s dot keshavamurthy at intel dot com>
- Cc: Masami Hiramatsu <hiramatu at sdl dot hitachi dot co dot jp>, Roland McGrath <roland at redhat dot com>, Richard J Moore <richardj_moore at uk dot ibm dot com>, SystemTAP <systemtap at sources dot redhat dot com>, sugita at sdl dot hitachi dot co dot jp, Satoshi Oshima <soshima at redhat dot com>
- Date: Wed, 27 Jul 2005 22:03:24 -0400
- Subject: Re: Hitachi djprobe mechanism
- Organization: Opersys inc.
- References: <44BDAFB888F59F408FAE3CC35AB4704101E506F6@orsmsx409> <42E83895.6070602@opersys.com>
- Reply-to: karim at opersys dot com
Karim Yaghmour wrote:
>From the article's text:
> "The springboard approach requires chunks of scratch space (collectively,
> the springboard heap) to be conveniently sprinkled throughout the kernel,
> so that every kernel instruction can reach some chunk when using one of
> the suitable instructions ..."
Also, there's this bit I missed from the figure the text refers to as
containing the list of instructions that can be used for various architectures
(figure 4.6):
"None of the architectures has an ideal splicing instruction; either
displacement is insufficient (RISC architectures), or there is no
guarantee that only a single instruction is overwritten when splicing (x86)."
To the best of my understanding, the latter seems to imply that springboards
have the very same limitations mentioned earlier for djprobe.
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