RE: patch for module function probe

RE: patch for module function probe

[Stone, Joshua I]

Roland McGrath wrote:
>> Yes, it might be.  It would be best if there was a way of
>> automagically supporting module("foo") for a foo that's compiled
>> into vmlinux with a CONFIG_FOO=y instead of CONFIG_FOO=m.  Does
>> kbuild leave any traces of the module ancestry in object files
>> produced this way? 
> 
> I don't think there is any way to recover that information.

Even if there were a way, this justs exacerbate the problem that started
this thread.  If CONFIG_FOO=y and someone also compiles and loads an
unrelated module foo, which would you turn to for resolving
module("foo")?


Josh

patch for module function probe

[Mao, Bibo]

Hi,
	Currently systemtap has some problem when searching module
function, which is reported in
http://sourceware.org/ml/systemtap/2006-q1/msg00674.html. Kernel is
treated as one module whose name is TOK_KERNEL "kernel". So this script
will pass to compile, it indeed will probe kernel function:
	probe module("kernel").function("sys_read"){
	}
But there will be problem when there is actually one module named
kernel.ko though its name is weird.

Bibo,mao

Here is patch for systemtap
--- src.org/tapsets.cxx 2006-04-03 16:19:09.000000000 +0800
+++ src/tapsets.cxx     2006-04-03 16:03:03.000000000 +0800
@@ -714,9 +714,13 @@ dwflpp
   void iterate_over_modules(int (* callback)(Dwfl_Module *, void **,
                                             const char *, Dwarf_Addr,
                                             void *),
-                           void * data)
+                           void * data, int has_module)
   {
-    ptrdiff_t off = 0;
+    ptrdiff_t off;
+
+    if (has_module)
+       off = 1;
+    else off = 0;
     do
       {
        off = dwfl_getmodules (dwfl, callback, data, off);
@@ -3204,12 +3208,12 @@ dwarf_builder::build(systemtap_session &
       if (q.has_kernel)
        {
          int flag = 0;
-         dw->iterate_over_modules(&query_kernel_exists, &flag);
+         dw->iterate_over_modules(&query_kernel_exists, &flag,
q.has_module);
          if (! flag)
            throw semantic_error ("cannot find kernel debuginfo");
        }

-      dw->iterate_over_modules(&query_module, &q);
+      dw->iterate_over_modules(&query_module, &q, q.has_module);
     }
 }

Re: patch for module function probe

[Li Guanglei]

Mao, Bibo :
> Hi,
> 	Currently systemtap has some problem when searching module
> function, which is reported in
> http://sourceware.org/ml/systemtap/2006-q1/msg00674.html. Kernel is
> treated as one module whose name is TOK_KERNEL "kernel". So this script
> will pass to compile, it indeed will probe kernel function:
> 	probe module("kernel").function("sys_read"){
> 	}
> But there will be problem when there is actually one module named
> kernel.ko though its name is weird.
> 
> Bibo,mao
> 
Actually, I think the expansion of module("*").function("foo") into 
kernel.function("foo") is a designed feature. It is especially useful 
for those compiled-in kernel modules. For example, in LKET, I can use:

probe addevent.scsi.iodispatching
= module("*").function("scsi_dispatch_cmd@drivers/scsi/scsi.c")

to let LKET work despite scsi_mod being compiled as a module or into 
the kernel.

Re: patch for module function probe

[bibo mao]

If it is designed feature, then kernel.function("foo") will be regarded 
as module("kernel").function("foo").  But if there is one module named 
"kernel.ko", how to probe its function although its module name is 
weird?  In another way to say what is the meaning of 
module("kernel").function("foo"), else stap manual clarify that 
module("kernel") means kernel image, user had better not use the same 
module name.


Li Guanglei wrote:
> Mao, Bibo :
>> Hi,
>>     Currently systemtap has some problem when searching module
>> function, which is reported in
>> http://sourceware.org/ml/systemtap/2006-q1/msg00674.html. Kernel is
>> treated as one module whose name is TOK_KERNEL "kernel". So this script
>> will pass to compile, it indeed will probe kernel function:
>>     probe module("kernel").function("sys_read"){
>>     }
>> But there will be problem when there is actually one module named
>> kernel.ko though its name is weird.
>>
>> Bibo,mao
>>
> Actually, I think the expansion of module("*").function("foo") into 
> kernel.function("foo") is a designed feature. It is especially useful 
> for those compiled-in kernel modules. For example, in LKET, I can use:
> 
> probe addevent.scsi.iodispatching
> = module("*").function("scsi_dispatch_cmd@drivers/scsi/scsi.c")
> 
> to let LKET work despite scsi_mod being compiled as a module or into the 
> kernel.
> 
> 
> 

Re: patch for module function probe

[Li Guanglei]

bibo mao :
> If it is designed feature, then kernel.function("foo") will be regarded 
> as module("kernel").function("foo").  But if there is one module named 
> "kernel.ko", how to probe its function although its module name is 
> weird?  In another way to say what is the meaning of 
> module("kernel").function("foo"), else stap manual clarify that 
> module("kernel") means kernel image, user had better not use the same 
> module name.

I tried and found:
module("kernel").function("foo") == kernel.function("foo"), which 
seems not appropriate.

I once thought module("*").function("foo") would be expanded as:
   module("aaa").function("foo")
   module("bbb").function("foo")
   module("kernel").function("foo")  // if happened to have a module 
named module which also has a function named foo
   ...
   kernel.function("foo")

That is to day, it should first search all loaded modules for function 
foo, then at last it will also search kernel image for function foo. 
So we need to change the current way it works with module("*").

Re: patch for module function probe

[Frank Ch. Eigler]

Li Guanglei <guanglei@cn.ibm.com> writes:

> Actually, I think the expansion of module("*").function("foo") into
> kernel.function("foo") is a designed feature.

No, it was an accident.

> It is especially useful for those compiled-in kernel modules. [...]

Yes, it might be.  It would be best if there was a way of
automagically supporting module("foo") for a foo that's compiled into
vmlinux with a CONFIG_FOO=y instead of CONFIG_FOO=m.  Does kbuild
leave any traces of the module ancestry in object files produced this
way?


- FChE

Re: patch for module function probe

[Roland McGrath]

> Yes, it might be.  It would be best if there was a way of automagically
> supporting module("foo") for a foo that's compiled into vmlinux with a
> CONFIG_FOO=y instead of CONFIG_FOO=m.  Does kbuild leave any traces of
> the module ancestry in object files produced this way?

I don't think there is any way to recover that information.