From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <systemtap-return-4996-listarch-systemtap=sources.redhat.com@sourceware.org>
Received: (qmail 2833 invoked by alias); 28 Nov 2006 00:05:47 -0000
Received: (qmail 2822 invoked by uid 22791); 28 Nov 2006 00:05:46 -0000
X-Spam-Status: No, hits=-2.5 required=5.0 	tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,TW_DJ
X-Spam-Check-By: sourceware.org
Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 28 Nov 2006 00:05:39 +0000
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) 	by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kAS05bx0007616 	for <systemtap@sources.redhat.com>; Mon, 27 Nov 2006 19:05:37 -0500
Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) 	by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kAS05Whr026116; 	Mon, 27 Nov 2006 19:05:32 -0500
Received: from [172.16.81.81] (murasaki.boston.redhat.com [172.16.81.81]) 	by mail.boston.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kAS05VFu011632; 	Mon, 27 Nov 2006 19:05:31 -0500
Message-ID: <456B7D4B.4050202@redhat.com>
Date: Tue, 28 Nov 2006 02:44:00 -0000
From: Satoshi Oshima <soshima@redhat.com>
User-Agent: Thunderbird 1.5.0.8 (X11/20061107)
MIME-Version: 1.0
To: "Frank Ch. Eigler" <fche@redhat.com>, Ingo Molnar <mingo@redhat.com>
CC: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,         "Keshavamurthy, Anil S" <anil.s.keshavamurthy@intel.com>,         SystemTAP <systemtap@sources.redhat.com>,         Ananth N Mavinakayanahalli <ananth@in.ibm.com>,         Prasanna S Panchamukhi <prasanna@in.ibm.com>,         Hideo Aoki <haoki@redhat.com>,         Yumiko Sugita <yumiko.sugita.yf@hitachi.com>,         Jim Keniston <jkenisto@us.ibm.com>, Martin Bligh <mbligh@google.com>,         Greg Kroah-Hartman <gregkh@suse.de>
Subject: Re: [RFC][PATCH 0/4][kprobe](djprobe) Direct jump optimized kprobes
References: <4562A150.2030606@hitachi.com> <1164632388.22536.109.camel@earth> <y0my7pwplqf.fsf@ton.toronto.redhat.com>
In-Reply-To: <y0my7pwplqf.fsf@ton.toronto.redhat.com>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <systemtap.sourceware.org>
List-Subscribe: <mailto:systemtap-subscribe@sourceware.org>
List-Post: <mailto:systemtap@sourceware.org>
List-Help: <mailto:systemtap-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: systemtap-owner@sourceware.org
X-SW-Source: 2006-q4/txt/msg00538.txt.bz2

Frank Ch. Eigler wrote:
> mingo wrote:
> 
>> [...]  I'm wondering whether it could be made a 100% transparent
>> speedup to kprobes: how hard would it be to do a simplified
>> disassembly of the target address to automate the 'this kprobe can
>> safely be turned into a djprobe transparently' step [...]
> 
> The entire criterion is not easy to check at the binary point.  In
> particular, it is hard to tell whether some part of the overlaid
> instruction sequence is the possible target of a branch elsewhere.

Yes. This is the problem. We couldn't find anything good way to
ensure the safety of branch target without debuginfo.

Now we are developing safety check tool that bases on
elfutils.

And during this safety check process, userspace tool must count
the length of replaced instructions. So we chose the length as
a trigger to enable djprobes. It is not the problem to count 
the length of instructions inside kernel. 

If you have any suggestion on this, we appreciate them.


Satoshi