public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Richard J Moore <richardj_moore@uk.ibm.com>
To: Mathieu Lacage <Mathieu.Lacage@sophia.inria.fr>
Cc: systemtap@sources.redhat.com
Subject: Re: Hitachi djprobe mechanism
Date: Fri, 07 Oct 2005 15:35:00 -0000	[thread overview]
Message-ID: <OF70F39591.E5887E85-ON41257093.0054AA39-41257093.0055669A@uk.ibm.com> (raw)
In-Reply-To: <1122975636.14331.236.camel@chronos>





I've  been back through the discussion on placement of a djprobe jmp on a
instruction less than the jmp size.  I don't see any resolution to this. As
far as I can see there is no safe way to overlay an instruction less than
the size of a jmp with a jmp. So for X86, djprobes would have to be
excluded from probepoints on instructions less than 5 bytes.

I don't see why block analysis is helpful. Unless one can guarantee fixing
up all jmp to an instruction following the probed instruction then we
simply cannot allow jmp to overlay anything smaller than its length.

So are we agreed that djprobe only operates under x86 on instructions >= 5
bytes?



- -
Richard J Moore
IBM Linux Technology Centre


                                                                           
             Mathieu Lacage                                                
             <Mathieu.Lacage                                               
             @sophia.inria.f                                            To 
             r>                        karim@opersys.com                   
             Sent by:                                                   cc 
             systemtap-owner           systemtap@sources.redhat.com        
             @sources.redhat                                           bcc 
             .com                                                          
                                                                   Subject 
                                       Re: Hitachi djprobe mechanism       
             02/08/2005                                                    
             10:40                                                         
                                                                           




[trimming the CC list and assuming all CCed persons are subscribed to
systemtap]

On Mon, 2005-08-01 at 16:31 -0400, Karim Yaghmour wrote:

> > step 3: (after all CPU pass safety check) replace with jmp
> >          instruction without first byte. leave int 3 instruction
> >          unchanged at this time (new step).
>
> This still fails to cover the very simple case I explained earlier:
>     if (...)
>           goto label;
>     <more code>
>     single_byte_asm_instruction_code();
> label:
>     foo();
>
> You still can't replace the instruction right before the label, and you'd
> have to have an integrated disassembler to go through all the code and
> make sure it too doesn't have a reference to the address of "label:".

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.

objdump -d -j .text /usr/lib/libgtk.so |./analysis.pl --print-stats
[...]
percentage of basic blocks bigger than 5 bytes: 97.45
bytes percentage of basic blocks bigger than 5 bytes: 99.68


objdump -d -j .text /usr/lib/libgtk-x11-2.0.so |./analysis.pl --print-
stats
[...]
percentage of basic blocks bigger than 5 bytes: 92.87
bytes percentage of basic blocks bigger than 5 bytes: 99.09


objdump -d -j .text /usr/X11R6/bin/X |./analysis.pl --print-stats
[...]
percentage of basic blocks bigger than 5 bytes: 96.63
bytes percentage of basic blocks bigger than 5 bytes: 99.60


objdump -d -j .text /usr/X11R6/lib/libX11.so |./analysis.pl --print-
stats
[...]
percentage of basic blocks bigger than 5 bytes: 96.98
bytes percentage of basic blocks bigger than 5 bytes: 99.60


I must say that I am pretty surprised by this rather positive result
which means that if you perform a proper bb-analysis of your binaries,
you should be able to put a probe almost anywhere in your binary without
much complicated instruction relocation work (modulo the issues related
to inserting and removing the probe itself).

regards,
Mathieu
--



#### analysis.pl has been deleted (was saved in repository MyAttachments
Repository ->(Document link: Link to the attachment in the repository))
from this note on 03 August 2005 by Richard J Moore

  parent reply	other threads:[~2005-10-07 15:35 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-27 21:05 Keshavamurthy, Anil S
2005-07-28  1:51 ` Karim Yaghmour
2005-07-28  2:10   ` Karim Yaghmour
2005-07-28 16:23     ` Masami Hiramatsu
2005-07-28 16:28       ` Karim Yaghmour
2005-07-28 17:36         ` Mathieu Desnoyers
     [not found]           ` <20050728110717.A30199@unix-os.sc.intel.com>
2005-07-28 18:33             ` Mathieu Desnoyers
     [not found]               ` <20050728133456.A32210@unix-os.sc.intel.com>
2005-07-28 23:53                 ` Richard J Moore
2005-07-29  5:59                 ` Mathieu Desnoyers
2005-07-29  7:55                   ` Andi Kleen
2005-07-29  8:44                     ` Richard J Moore
2005-07-29  8:46                       ` Andi Kleen
2005-07-29 15:51                     ` Mathieu Desnoyers
2005-07-30 15:55                       ` Andi Kleen
2005-07-30 16:54                         ` Mathieu Desnoyers
2005-07-31 22:03                           ` Andi Kleen
2005-07-31 23:11                             ` Mathieu Desnoyers
2005-08-01 15:37                               ` Andi Kleen
2005-08-01  8:44                             ` Richard J Moore
2005-08-01 13:21                               ` Mathieu Desnoyers
2005-08-01 19:57                               ` Satoshi Oshima
2005-08-01 20:21                                 ` Karim Yaghmour
2005-08-01 22:12                                   ` Satoshi Oshima
2005-08-01 22:54                                     ` Karim Yaghmour
2005-08-02 18:42                                       ` Satoshi Oshima
2005-08-03 14:50                                         ` Karim Yaghmour
2005-08-04  1:19                                         ` Mathieu Desnoyers
2005-08-04  3:31                                           ` Mathieu Desnoyers
2005-08-02  9:42                                   ` Mathieu Lacage
2005-08-02 15:09                                     ` Karim Yaghmour
2005-10-07 15:35                                     ` Richard J Moore [this message]
2005-10-08 18:33                                       ` mathieu lacage
2005-10-08 21:59                                         ` Richard J Moore
2005-10-08 23:24                                           ` Roland McGrath
2005-10-22 11:49                                             ` mathieu lacage
2005-10-22 22:09                                               ` Roland McGrath
2005-10-24  6:33                                                 ` Mathieu Lacage
2005-10-24 19:48                                                   ` Roland McGrath
     [not found]                                             ` <43621B0D.70204@sophia.inria.fr>
2005-11-07 10:04                                               ` mathieu lacage
2005-11-07 10:06                                                 ` mathieu lacage
2005-11-08  9:49                                             ` Richard J Moore
2005-10-09 16:47                                           ` mathieu lacage
2005-08-02 15:33                                   ` Mathieu Lacage
2005-08-02 15:36                                     ` Mathieu Lacage
2005-08-02 16:12                                     ` Karim Yaghmour
2005-08-02 16:30                                       ` Mathieu Lacage
2005-08-02 16:46                                         ` Karim Yaghmour
2005-08-04 17:09                                         ` Mathieu Lacage
2005-08-03 14:46                                 ` Andi Kleen
2005-07-29 16:06                   ` Frank Ch. Eigler
2005-07-29 18:24                     ` sugita
2005-07-28 18:13       ` Richard J Moore
  -- strict thread matches above, loose matches on Subject: below --
2005-08-01 22:49 Keshavamurthy, Anil S
2005-08-01 23:05 ` Karim Yaghmour
2005-08-01 23:18   ` Karim Yaghmour
2005-08-01 22:41 Keshavamurthy, Anil S
2005-08-02  3:21 ` Roland McGrath
2005-08-02  3:35   ` Karim Yaghmour
2005-08-01 20:46 Keshavamurthy, Anil S
2005-08-01 21:08 ` Karim Yaghmour
2005-08-01 16:14 Keshavamurthy, Anil S
2005-08-01 20:31 ` Roland McGrath
2005-08-04  0:28   ` Mathieu Desnoyers
2005-08-04 10:01     ` Andi Kleen
2005-08-05 16:25       ` Mathieu Desnoyers
2005-08-05 16:39         ` Andi Kleen
2005-08-01 15:50 Keshavamurthy, Anil S
2005-08-01 16:03 ` Mathieu Desnoyers
2005-07-29  0:18 Keshavamurthy, Anil S
2005-07-29  1:48 ` Karim Yaghmour
2005-07-29  3:41   ` Mathieu Desnoyers
2005-07-29  3:47     ` Karim Yaghmour
2005-07-29  1:53 ` Frank Ch. Eigler
2005-08-01  9:02   ` Mathieu Lacage
2005-08-01 13:18     ` Mathieu Desnoyers
2005-08-02  7:07       ` Mathieu Lacage
2005-07-22 18:09 Frank Ch. Eigler
2005-07-21 22:32 Richard J Moore
2005-07-21 22:52 ` Roland McGrath
2005-07-22  2:52   ` Richard J Moore
2005-07-26  7:14   ` Masami Hiramatsu
2005-07-26  7:53     ` Roland McGrath
2005-07-27 13:02       ` Masami Hiramatsu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=OF70F39591.E5887E85-ON41257093.0054AA39-41257093.0055669A@uk.ibm.com \
    --to=richardj_moore@uk.ibm.com \
    --cc=Mathieu.Lacage@sophia.inria.fr \
    --cc=systemtap@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).