From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19783 invoked by alias); 2 Aug 2005 15:09:48 -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 19769 invoked by uid 22791); 2 Aug 2005 15:09:43 -0000 Message-ID: <42EF8F38.5040309@opersys.com> Date: Tue, 02 Aug 2005 15:09:00 -0000 From: Karim Yaghmour Reply-To: karim@opersys.com Organization: Opersys inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en, fr, fr-be, fr-ca, fr-fr MIME-Version: 1.0 To: Mathieu Lacage CC: systemtap@sources.redhat.com Subject: Re: Hitachi djprobe mechanism References: <42EE7E97.7080501@redhat.com> <42EE86AD.609@opersys.com> <1122975636.14331.236.camel@chronos> In-Reply-To: <1122975636.14331.236.camel@chronos> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2005-q3/txt/msg00235.txt.bz2 Mathieu Lacage wrote: > This problem probably should be addressed in userspace and the way this > should be solved is by calculating the location of the basic blocks of > the function in which you want to insert the probe. Then, any basic > block bigger than 5 bytes will be an acceptable candidate for probe > insertion. > > Clearly, this is one of the reasons the kerninst people built a system- > wide daemon which did perform the basic-block calculation. > > The attached ugly perl script evaluates the basic blocks and outputs > statistics about their size. Please, note the "evaluate" verb used > above. It means that I am pretty sure this script is not 100% reliable > but it should give non-skewed results given the size of most binaries. > Beware: this thing will suck away your CPU time. This would certainly be a step in the right direction. I too am suprised of the results. It would really be interesting to see how this compares to the output from the compiler, as Michel suggests. ... there's still that problem of finding out what's on a process' stack though ... 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