From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 795 invoked by alias); 2 Aug 2005 15:33:41 -0000 Mailing-List: contact systemtap-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sources.redhat.com Received: (qmail 764 invoked by uid 22791); 2 Aug 2005 15:33:37 -0000 Subject: Re: Hitachi djprobe mechanism From: Mathieu Lacage To: karim@opersys.com Cc: systemtap@sources.redhat.com In-Reply-To: <42EE86AD.609@opersys.com> References: <42EE7E97.7080501@redhat.com> <42EE86AD.609@opersys.com> Content-Type: text/plain Date: Tue, 02 Aug 2005 15:33:00 -0000 Message-Id: <1122996753.14331.250.camel@chronos> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sophia.inria.fr [138.96.64.20]); Tue, 02 Aug 2005 17:32:34 +0200 (MEST) X-Virus-Scanned: by amavisd-new at sophia.inria.fr X-SW-Source: 2005-q3/txt/msg00236.txt.bz2 [trimming CC list again] On Mon, 2005-08-01 at 16:31 -0400, Karim Yaghmour wrote: > Satoshi Oshima wrote: > > step 2: safety check; > > make sure that all CPUs don't run on the code that will > > be replaced with jmp instruction (also check whether stack > > include EIP of the code which is subject to replace) > > Please explain exactly how you will make sure that there is no pre-existing > reference to any of the replaced instructions, whether it be on the stack > or elsewhere. Consider a system that has many thousands of processes running > in parallel on different CPUs. > > Also consider that you may find things on the stack that look like address > references to the range you wish to replace, but are actually valid data. I have probably missed something here but I would appreciate if you could point me to my mistake. The only reasonable reason why you would see the EIP of an instruction somewhere on the stack is because it was pushed there as: - a function argument as a function callback. - the return address of a call statement. In both cases, these EIPs represent the start of a basic block which means that, if you follow my earlier suggestion of calculating carefully the complete basic-block tree of your functions to avoid inserting probes at basic-block boundaries, you should be able to always ensure that these EIPs stay valid. At worst, if they are used by some piece of code, the code will jump back to the old basic-block which will immediately jump to its probe because its first instruction is the probe jump. regards, Mathieu --