add an option, let the systemtap doesn't check whether the probe point is at the start of an assembly instruction

add an option, let the systemtap doesn't check whether the probe point is at the start of an assembly instruction

[peng yu]

Hi, list.

I found systemtap verify whether a raw address matches the beginning
of a statement. Systemtap use this method to check whether the address
is at the start of an assembly instruction. But sometimes, I really
need to probe an address which is not at the start of a statement. For
example, below is a piece of disassemble instructions:

/usr/src/debug/kernel-2.6.18/linux-2.6.18.i686/arch/i386/mm/highmem.c: 70
0xc041df94 <kunmap_atomic+64>:  mov    0xc079d24c,%eax
0xc041df99 <kunmap_atomic+69>:  lea    0x0(,%ecx,8),%edx
0xc041dfa0 <kunmap_atomic+76>:  sub    %edx,%eax

I want to see the value in eax before "sub %edx, %eax" and after "mov
0xc079d24c,%eax", but systemtap forbid me to probe the address
"0xc041df99". I think it is useful if the stap command can accept a
new cmdline option,  let it don't do the address valid check. So such
systemtap script can work: "probe kernel.statement(0xc041df99)".

Below is a patch, I test it on the systemtap-1.8, after apply the
patch, we can use a '-i' option when call stap command, let the
systemtap don't do the address valid check.

diff -Nurp systemtap-1.8.ori/cmdline.h systemtap-1.8/cmdline.h
--- systemtap-1.8.ori/cmdline.h	2012-07-16 12:06:02.911200148 +0800
+++ systemtap-1.8/cmdline.h	2012-07-16 12:08:20.137189928 +0800
@@ -58,7 +58,7 @@ enum {

 // NB: when adding new options, consider very carefully whether they
 // should be restricted from stap clients (after --client-options)!
-#define STAP_SHORT_OPTIONS "hVvtp:I:e:o:R:r:a:m:kgPc:x:D:bs:uqwl:d:L:FS:B:WG:"
+#define STAP_SHORT_OPTIONS "hVvtp:I:e:o:R:r:a:m:kgPc:x:D:bs:uqwl:d:L:FS:B:WG:i"

 #define OWE5 "tter"
 #define OWE1 "uild-"
diff -Nurp systemtap-1.8.ori/session.cxx systemtap-1.8/session.cxx
--- systemtap-1.8.ori/session.cxx	2012-07-16 12:06:02.910188209 +0800
+++ systemtap-1.8/session.cxx	2012-07-16 12:08:20.136188467 +0800
@@ -105,6 +105,7 @@ systemtap_session::systemtap_session ():
   listing_mode = false;
   listing_mode_vars = false;
   dump_probe_types = false;
+  ignore_address_check = false;

 #ifdef ENABLE_PROLOGUES
   prologue_searching = true;
@@ -844,6 +845,11 @@ systemtap_session::parse_cmdline (int ar
           kbuildflags.push_back (string (optarg));
 	  break;

+        case 'i':
+          server_args.push_back (string ("-") + (char)grc);
+          ignore_address_check = true;
+          break;
+
 	case LONG_OPT_VERSION:
 	  version ();
 	  exit (0);
diff -Nurp systemtap-1.8.ori/session.h systemtap-1.8/session.h
--- systemtap-1.8.ori/session.h	2012-07-16 12:06:03.053189385 +0800
+++ systemtap-1.8/session.h	2012-07-16 12:08:20.276189957 +0800
@@ -179,6 +179,7 @@ public:
   bool unoptimized;
   bool suppress_warnings;
   bool panic_warnings;
+  bool ignore_address_check;
   int buffer_size;
   bool prologue_searching;
   bool tapset_compile_coverage;
diff -Nurp systemtap-1.8.ori/tapsets.cxx systemtap-1.8/tapsets.cxx
--- systemtap-1.8.ori/tapsets.cxx	2012-07-16 12:06:03.031191674 +0800
+++ systemtap-1.8/tapsets.cxx	2012-07-16 12:08:20.255189907 +0800
@@ -1400,7 +1400,7 @@ query_addr(Dwarf_Addr addr, dwarf_query
       // is at the start of an assembly instruction.  Mark probes are in the
       // middle of a macro and thus not strictly at a statement beginning.
       // Guru mode may override this check.
-      if (!q->has_mark && (!address_line || address_line.addr() != addr))
+      if (!q->has_mark && !dw.sess.ignore_address_check &&
(!address_line || address_line.addr() != addr))
         {
           stringstream msg;
           msg << _F("address %#" PRIx64 " does not match the
beginning of a statement",

Re: add an option, let the systemtap doesn't check whether the probe point is at the start of an assembly instruction

[Timo Juhani Lindfors]

peng yu <yupeng0921@gmail.com> writes:
> Below is a patch, I test it on the systemtap-1.8, after apply the
> patch, we can use a '-i' option when call stap command, let the
> systemtap don't do the address valid check.

As a user it sounds bit dangerous to use a short option for something
like this.

Re: add an option, let the systemtap doesn't check whether the probe point is at the start of an assembly instruction

[peng yu]

Yes, I agree. Use a long option may be better.

On Mon, Jul 16, 2012 at 3:52 PM, Timo Juhani Lindfors
<timo.lindfors@iki.fi> wrote:
> peng yu <yupeng0921@gmail.com> writes:
>> Below is a patch, I test it on the systemtap-1.8, after apply the
>> patch, we can use a '-i' option when call stap command, let the
>> systemtap don't do the address valid check.
>
> As a user it sounds bit dangerous to use a short option for something
> like this.

Re: add an option, let the systemtap doesn't check whether the probe point is at the start of an assembly instruction

[Frank Ch. Eigler]

peng yu <yupeng0921@gmail.com> writes:

> [...]
> But sometimes, I really
> need to probe an address which is not at the start of a statement. [...]
> [...] I think it is useful if the stap command can accept a
> new cmdline option,  let it don't do the address valid check. So such
> systemtap script can work: "probe kernel.statement(0xc041df99)".

Thanks for the patch.  But before we dig into that further, have you
tried 

# stap -g 'probe kernel.statement(0xc041df99).absolute {}'

?

- FChE

Re: add an option, let the systemtap doesn't check whether the probe point is at the start of an assembly instruction

[peng yu]

Thanks, it work!

On Mon, Jul 16, 2012 at 11:33 PM, Frank Ch. Eigler <fche@redhat.com> wrote:
> peng yu <yupeng0921@gmail.com> writes:
>
>> [...]
>> But sometimes, I really
>> need to probe an address which is not at the start of a statement. [...]
>> [...] I think it is useful if the stap command can accept a
>> new cmdline option,  let it don't do the address valid check. So such
>> systemtap script can work: "probe kernel.statement(0xc041df99)".
>
> Thanks for the patch.  But before we dig into that further, have you
> tried
>
> # stap -g 'probe kernel.statement(0xc041df99).absolute {}'
>
> ?
>
> - FChE