Calling systemtap function from pure code

Calling systemtap function from pure code

[Daniel Doron]

Hi,

Is it possible to call a stap function from kernel code (guru mode)?

The error I get is:
 error: implicit declaration of function ‘log_evnt_stap’
[-Werror=implicit-function-declaration]

e.g.:
=============================
function log_evnt_stap(name){
    printf("name %s \n", name )
}

probe begin(0) {
  call_me();
}

%{

int log_event(char * str)
{
     log_evnt_stap(str);
     return 0;
}

%}

function call_me() %{
     log_event("hello world");
%}
================================

Re: Calling systemtap function from pure code

[David Smith]

On Wed, Sep 13, 2017 at 9:41 AM, Daniel Doron <danielmeirdoron@gmail.com> wrote:
> Hi,
>
> Is it possible to call a stap function from kernel code (guru mode)?

No, not really.

Yes, all stap language functions get translated to a C function.
However, you can't call that function easily, for several reasons:

1) The stap language function name gets mangled when it gets
translated to C. That mangling isn't documented and changes from time
to time. The last time it changed was when we implemented function
overloading. We have no plans to document the current mangling scheme
(you could certainly figure it out looking at the generated output)
and we reserve the right to change the mangling scheme in the future.

2) Even if you know the correct C function name for a stap language
function, you can't easily call it. Function parameters aren't passed
on the stack, they are passed in a context structure, which once again
is undocumented and subject to change.

I'm not really sure what you are really trying to do here, but if you
need to call common code from a stap language function and a C
function, I'd put that functionality in a C function, then write a
stap language wrapper for it. Something like the following (untested):

====
%{

int internal_log_event(char *str)
{
    printk(KERN_INFO "name: %s\n", str);
    return 0;
}

%}

function log_event:long(str:string)
%{
    STAP_RETVALUE = internal_log_event(STAP_ARG_str);
%}

function call_me()
{
    log_event("hello world")
}

probe begin {
    call_me()
}
====

Note that the STAP_ARG_ function argument prefix and STAP_RETVALUE
item are documented and are supported.

If this doesn't answer your question, you'll need to let us know what
you are really trying to do.

-- 
David Smith
Principal Software Engineer
Red Hat

Re: Calling systemtap function from pure code

[Daniel Doron]

I will explain....
i wanted to get as much info on kernel module insertion/removal but
the init_module/delete_module probe points do not provide enough
information. So , I thought about load_module() which does provide
adequate info via struct module (local var),  but this gets filled
along the way and I can;t really have access to it via systemtap. So I
thought the simplest way to access that struct is though notification
chain, i.e. use register_module_notifier() and extract the info from
the struct there and then print it via systemtap.
So I guess the right question would be how to access the STAP print
function/mechanism/buffer...from standard kernel code.

Thanks.

On Thu, Sep 14, 2017 at 12:22 AM, David Smith <dsmith@redhat.com> wrote:
> On Wed, Sep 13, 2017 at 9:41 AM, Daniel Doron <danielmeirdoron@gmail.com> wrote:
>> Hi,
>>
>> Is it possible to call a stap function from kernel code (guru mode)?
>
> No, not really.
>
> Yes, all stap language functions get translated to a C function.
> However, you can't call that function easily, for several reasons:
>
> 1) The stap language function name gets mangled when it gets
> translated to C. That mangling isn't documented and changes from time
> to time. The last time it changed was when we implemented function
> overloading. We have no plans to document the current mangling scheme
> (you could certainly figure it out looking at the generated output)
> and we reserve the right to change the mangling scheme in the future.
>
> 2) Even if you know the correct C function name for a stap language
> function, you can't easily call it. Function parameters aren't passed
> on the stack, they are passed in a context structure, which once again
> is undocumented and subject to change.
>
> I'm not really sure what you are really trying to do here, but if you
> need to call common code from a stap language function and a C
> function, I'd put that functionality in a C function, then write a
> stap language wrapper for it. Something like the following (untested):
>
> ====
> %{
>
> int internal_log_event(char *str)
> {
>     printk(KERN_INFO "name: %s\n", str);
>     return 0;
> }
>
> %}
>
> function log_event:long(str:string)
> %{
>     STAP_RETVALUE = internal_log_event(STAP_ARG_str);
> %}
>
> function call_me()
> {
>     log_event("hello world")
> }
>
> probe begin {
>     call_me()
> }
> ====
>
> Note that the STAP_ARG_ function argument prefix and STAP_RETVALUE
> item are documented and are supported.
>
> If this doesn't answer your question, you'll need to let us know what
> you are really trying to do.
>
> --
> David Smith
> Principal Software Engineer
> Red Hat

Re: Calling systemtap function from pure code

[Arkady]

I am not sure that I understand the goal. Please provide more details
or rephrase the mail.

This is an example of a patch in the SystemTap which allows to add
code to the load/remove module flow
https://github.com/larytet/SystemTap/commit/6e4c99f96c9ecce9508f2c8612e8bace2ac91ae5

On Thu, Sep 14, 2017 at 10:20 AM, Daniel Doron
<danielmeirdoron@gmail.com> wrote:
> I will explain....
> i wanted to get as much info on kernel module insertion/removal but
> the init_module/delete_module probe points do not provide enough
> information. So , I thought about load_module() which does provide
> adequate info via struct module (local var),  but this gets filled
> along the way and I can;t really have access to it via systemtap. So I
> thought the simplest way to access that struct is though notification
> chain, i.e. use register_module_notifier() and extract the info from
> the struct there and then print it via systemtap.
> So I guess the right question would be how to access the STAP print
> function/mechanism/buffer...from standard kernel code.
>
> Thanks.
>
> On Thu, Sep 14, 2017 at 12:22 AM, David Smith <dsmith@redhat.com> wrote:
>> On Wed, Sep 13, 2017 at 9:41 AM, Daniel Doron <danielmeirdoron@gmail.com> wrote:
>>> Hi,
>>>
>>> Is it possible to call a stap function from kernel code (guru mode)?
>>
>> No, not really.
>>
>> Yes, all stap language functions get translated to a C function.
>> However, you can't call that function easily, for several reasons:
>>
>> 1) The stap language function name gets mangled when it gets
>> translated to C. That mangling isn't documented and changes from time
>> to time. The last time it changed was when we implemented function
>> overloading. We have no plans to document the current mangling scheme
>> (you could certainly figure it out looking at the generated output)
>> and we reserve the right to change the mangling scheme in the future.
>>
>> 2) Even if you know the correct C function name for a stap language
>> function, you can't easily call it. Function parameters aren't passed
>> on the stack, they are passed in a context structure, which once again
>> is undocumented and subject to change.
>>
>> I'm not really sure what you are really trying to do here, but if you
>> need to call common code from a stap language function and a C
>> function, I'd put that functionality in a C function, then write a
>> stap language wrapper for it. Something like the following (untested):
>>
>> ====
>> %{
>>
>> int internal_log_event(char *str)
>> {
>>     printk(KERN_INFO "name: %s\n", str);
>>     return 0;
>> }
>>
>> %}
>>
>> function log_event:long(str:string)
>> %{
>>     STAP_RETVALUE = internal_log_event(STAP_ARG_str);
>> %}
>>
>> function call_me()
>> {
>>     log_event("hello world")
>> }
>>
>> probe begin {
>>     call_me()
>> }
>> ====
>>
>> Note that the STAP_ARG_ function argument prefix and STAP_RETVALUE
>> item are documented and are supported.
>>
>> If this doesn't answer your question, you'll need to let us know what
>> you are really trying to do.
>>
>> --
>> David Smith
>> Principal Software Engineer
>> Red Hat

Re: Calling systemtap function from pure code

[Arkady]

I read your e-mail a couple of times and probably I got it. You
want to know inside the systemtap script some details about the kernel
module the script is part of.

The easiest way to do this is to load a non-STAP kernel module which
contains a data structure with all the data. The steps:
* Load the stap driver, make sure that probe begin blocks until there
is an exported variable "Daniel" in the kernel and the value of the
variable is True.
* Collect the data you need from the user space, insmod a small kernel
module with the data, collect more data from the kernel if needed, set
the exported variable to True.
* At this point probe begin discovers an exported variable "Daniel"
and can continue.


If the kernel keeps the relevant data somewhere "probe begin" can try
to fetch the data from the kernel.

On Thu, Sep 14, 2017 at 10:20 AM, Daniel Doron
<danielmeirdoron@gmail.com> wrote:
> I will explain....
> i wanted to get as much info on kernel module insertion/removal but
> the init_module/delete_module probe points do not provide enough
> information. So , I thought about load_module() which does provide
> adequate info via struct module (local var),  but this gets filled
> along the way and I can;t really have access to it via systemtap. So I
> thought the simplest way to access that struct is though notification
> chain, i.e. use register_module_notifier() and extract the info from
> the struct there and then print it via systemtap.
> So I guess the right question would be how to access the STAP print
> function/mechanism/buffer...from standard kernel code.
>
> Thanks.
>
> On Thu, Sep 14, 2017 at 12:22 AM, David Smith <dsmith@redhat.com> wrote:
>> On Wed, Sep 13, 2017 at 9:41 AM, Daniel Doron <danielmeirdoron@gmail.com> wrote:
>>> Hi,
>>>
>>> Is it possible to call a stap function from kernel code (guru mode)?
>>
>> No, not really.
>>
>> Yes, all stap language functions get translated to a C function.
>> However, you can't call that function easily, for several reasons:
>>
>> 1) The stap language function name gets mangled when it gets
>> translated to C. That mangling isn't documented and changes from time
>> to time. The last time it changed was when we implemented function
>> overloading. We have no plans to document the current mangling scheme
>> (you could certainly figure it out looking at the generated output)
>> and we reserve the right to change the mangling scheme in the future.
>>
>> 2) Even if you know the correct C function name for a stap language
>> function, you can't easily call it. Function parameters aren't passed
>> on the stack, they are passed in a context structure, which once again
>> is undocumented and subject to change.
>>
>> I'm not really sure what you are really trying to do here, but if you
>> need to call common code from a stap language function and a C
>> function, I'd put that functionality in a C function, then write a
>> stap language wrapper for it. Something like the following (untested):
>>
>> ====
>> %{
>>
>> int internal_log_event(char *str)
>> {
>>     printk(KERN_INFO "name: %s\n", str);
>>     return 0;
>> }
>>
>> %}
>>
>> function log_event:long(str:string)
>> %{
>>     STAP_RETVALUE = internal_log_event(STAP_ARG_str);
>> %}
>>
>> function call_me()
>> {
>>     log_event("hello world")
>> }
>>
>> probe begin {
>>     call_me()
>> }
>> ====
>>
>> Note that the STAP_ARG_ function argument prefix and STAP_RETVALUE
>> item are documented and are supported.
>>
>> If this doesn't answer your question, you'll need to let us know what
>> you are really trying to do.
>>
>> --
>> David Smith
>> Principal Software Engineer
>> Red Hat

Re: Calling systemtap function from pure code

[Daniel Doron]

I meant to generally, system wide, probe any kernel module
insertion/removal and hence I wanted to extract information about the
module being inserted/removed and print it out. Hence, the usage of
the module notifier chain, which provide access to struct_module.

On Thu, Sep 14, 2017 at 10:31 AM, Arkady <arkady.miasnikov@gmail.com> wrote:
> I am not sure that I understand the goal. Please provide more details
> or rephrase the mail.
>
> This is an example of a patch in the SystemTap which allows to add
> code to the load/remove module flow
> https://github.com/larytet/SystemTap/commit/6e4c99f96c9ecce9508f2c8612e8bace2ac91ae5
>
> On Thu, Sep 14, 2017 at 10:20 AM, Daniel Doron
> <danielmeirdoron@gmail.com> wrote:
>> I will explain....
>> i wanted to get as much info on kernel module insertion/removal but
>> the init_module/delete_module probe points do not provide enough
>> information. So , I thought about load_module() which does provide
>> adequate info via struct module (local var),  but this gets filled
>> along the way and I can;t really have access to it via systemtap. So I
>> thought the simplest way to access that struct is though notification
>> chain, i.e. use register_module_notifier() and extract the info from
>> the struct there and then print it via systemtap.
>> So I guess the right question would be how to access the STAP print
>> function/mechanism/buffer...from standard kernel code.
>>
>> Thanks.
>>
>> On Thu, Sep 14, 2017 at 12:22 AM, David Smith <dsmith@redhat.com> wrote:
>>> On Wed, Sep 13, 2017 at 9:41 AM, Daniel Doron <danielmeirdoron@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> Is it possible to call a stap function from kernel code (guru mode)?
>>>
>>> No, not really.
>>>
>>> Yes, all stap language functions get translated to a C function.
>>> However, you can't call that function easily, for several reasons:
>>>
>>> 1) The stap language function name gets mangled when it gets
>>> translated to C. That mangling isn't documented and changes from time
>>> to time. The last time it changed was when we implemented function
>>> overloading. We have no plans to document the current mangling scheme
>>> (you could certainly figure it out looking at the generated output)
>>> and we reserve the right to change the mangling scheme in the future.
>>>
>>> 2) Even if you know the correct C function name for a stap language
>>> function, you can't easily call it. Function parameters aren't passed
>>> on the stack, they are passed in a context structure, which once again
>>> is undocumented and subject to change.
>>>
>>> I'm not really sure what you are really trying to do here, but if you
>>> need to call common code from a stap language function and a C
>>> function, I'd put that functionality in a C function, then write a
>>> stap language wrapper for it. Something like the following (untested):
>>>
>>> ====
>>> %{
>>>
>>> int internal_log_event(char *str)
>>> {
>>>     printk(KERN_INFO "name: %s\n", str);
>>>     return 0;
>>> }
>>>
>>> %}
>>>
>>> function log_event:long(str:string)
>>> %{
>>>     STAP_RETVALUE = internal_log_event(STAP_ARG_str);
>>> %}
>>>
>>> function call_me()
>>> {
>>>     log_event("hello world")
>>> }
>>>
>>> probe begin {
>>>     call_me()
>>> }
>>> ====
>>>
>>> Note that the STAP_ARG_ function argument prefix and STAP_RETVALUE
>>> item are documented and are supported.
>>>
>>> If this doesn't answer your question, you'll need to let us know what
>>> you are really trying to do.
>>>
>>> --
>>> David Smith
>>> Principal Software Engineer
>>> Red Hat

Re: Calling systemtap function from pure code

[Daniel Doron]

Hi Arkady,

not what I meant but does provide an answer to another problem I was
having ;-) Thanks.

On Thu, Sep 14, 2017 at 10:40 AM, Arkady <arkady.miasnikov@gmail.com> wrote:
> I read your e-mail a couple of times and probably I got it. You
> want to know inside the systemtap script some details about the kernel
> module the script is part of.
>
> The easiest way to do this is to load a non-STAP kernel module which
> contains a data structure with all the data. The steps:
> * Load the stap driver, make sure that probe begin blocks until there
> is an exported variable "Daniel" in the kernel and the value of the
> variable is True.
> * Collect the data you need from the user space, insmod a small kernel
> module with the data, collect more data from the kernel if needed, set
> the exported variable to True.
> * At this point probe begin discovers an exported variable "Daniel"
> and can continue.
>
>
> If the kernel keeps the relevant data somewhere "probe begin" can try
> to fetch the data from the kernel.
>
> On Thu, Sep 14, 2017 at 10:20 AM, Daniel Doron
> <danielmeirdoron@gmail.com> wrote:
>> I will explain....
>> i wanted to get as much info on kernel module insertion/removal but
>> the init_module/delete_module probe points do not provide enough
>> information. So , I thought about load_module() which does provide
>> adequate info via struct module (local var),  but this gets filled
>> along the way and I can;t really have access to it via systemtap. So I
>> thought the simplest way to access that struct is though notification
>> chain, i.e. use register_module_notifier() and extract the info from
>> the struct there and then print it via systemtap.
>> So I guess the right question would be how to access the STAP print
>> function/mechanism/buffer...from standard kernel code.
>>
>> Thanks.
>>
>> On Thu, Sep 14, 2017 at 12:22 AM, David Smith <dsmith@redhat.com> wrote:
>>> On Wed, Sep 13, 2017 at 9:41 AM, Daniel Doron <danielmeirdoron@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> Is it possible to call a stap function from kernel code (guru mode)?
>>>
>>> No, not really.
>>>
>>> Yes, all stap language functions get translated to a C function.
>>> However, you can't call that function easily, for several reasons:
>>>
>>> 1) The stap language function name gets mangled when it gets
>>> translated to C. That mangling isn't documented and changes from time
>>> to time. The last time it changed was when we implemented function
>>> overloading. We have no plans to document the current mangling scheme
>>> (you could certainly figure it out looking at the generated output)
>>> and we reserve the right to change the mangling scheme in the future.
>>>
>>> 2) Even if you know the correct C function name for a stap language
>>> function, you can't easily call it. Function parameters aren't passed
>>> on the stack, they are passed in a context structure, which once again
>>> is undocumented and subject to change.
>>>
>>> I'm not really sure what you are really trying to do here, but if you
>>> need to call common code from a stap language function and a C
>>> function, I'd put that functionality in a C function, then write a
>>> stap language wrapper for it. Something like the following (untested):
>>>
>>> ====
>>> %{
>>>
>>> int internal_log_event(char *str)
>>> {
>>>     printk(KERN_INFO "name: %s\n", str);
>>>     return 0;
>>> }
>>>
>>> %}
>>>
>>> function log_event:long(str:string)
>>> %{
>>>     STAP_RETVALUE = internal_log_event(STAP_ARG_str);
>>> %}
>>>
>>> function call_me()
>>> {
>>>     log_event("hello world")
>>> }
>>>
>>> probe begin {
>>>     call_me()
>>> }
>>> ====
>>>
>>> Note that the STAP_ARG_ function argument prefix and STAP_RETVALUE
>>> item are documented and are supported.
>>>
>>> If this doesn't answer your question, you'll need to let us know what
>>> you are really trying to do.
>>>
>>> --
>>> David Smith
>>> Principal Software Engineer
>>> Red Hat

Re: Calling systemtap function from pure code

[Arkady]

You will not be able to call many of the kernel functions from STAP
probes. Specifically you can not call any kernel API which a mutex.
For example, you will not be able to call register_module_notifier()
API from within STAP probes without using the patch I mentioned above.

On Thu, Sep 14, 2017 at 10:42 AM, Daniel Doron
<danielmeirdoron@gmail.com> wrote:
> I meant to generally, system wide, probe any kernel module
> insertion/removal and hence I wanted to extract information about the
> module being inserted/removed and print it out. Hence, the usage of
> the module notifier chain, which provide access to struct_module.
>
> On Thu, Sep 14, 2017 at 10:31 AM, Arkady <arkady.miasnikov@gmail.com> wrote:
>> I am not sure that I understand the goal. Please provide more details
>> or rephrase the mail.
>>
>> This is an example of a patch in the SystemTap which allows to add
>> code to the load/remove module flow
>> https://github.com/larytet/SystemTap/commit/6e4c99f96c9ecce9508f2c8612e8bace2ac91ae5
>>
>> On Thu, Sep 14, 2017 at 10:20 AM, Daniel Doron
>> <danielmeirdoron@gmail.com> wrote:
>>> I will explain....
>>> i wanted to get as much info on kernel module insertion/removal but
>>> the init_module/delete_module probe points do not provide enough
>>> information. So , I thought about load_module() which does provide
>>> adequate info via struct module (local var),  but this gets filled
>>> along the way and I can;t really have access to it via systemtap. So I
>>> thought the simplest way to access that struct is though notification
>>> chain, i.e. use register_module_notifier() and extract the info from
>>> the struct there and then print it via systemtap.
>>> So I guess the right question would be how to access the STAP print
>>> function/mechanism/buffer...from standard kernel code.
>>>
>>> Thanks.
>>>
>>> On Thu, Sep 14, 2017 at 12:22 AM, David Smith <dsmith@redhat.com> wrote:
>>>> On Wed, Sep 13, 2017 at 9:41 AM, Daniel Doron <danielmeirdoron@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> Is it possible to call a stap function from kernel code (guru mode)?
>>>>
>>>> No, not really.
>>>>
>>>> Yes, all stap language functions get translated to a C function.
>>>> However, you can't call that function easily, for several reasons:
>>>>
>>>> 1) The stap language function name gets mangled when it gets
>>>> translated to C. That mangling isn't documented and changes from time
>>>> to time. The last time it changed was when we implemented function
>>>> overloading. We have no plans to document the current mangling scheme
>>>> (you could certainly figure it out looking at the generated output)
>>>> and we reserve the right to change the mangling scheme in the future.
>>>>
>>>> 2) Even if you know the correct C function name for a stap language
>>>> function, you can't easily call it. Function parameters aren't passed
>>>> on the stack, they are passed in a context structure, which once again
>>>> is undocumented and subject to change.
>>>>
>>>> I'm not really sure what you are really trying to do here, but if you
>>>> need to call common code from a stap language function and a C
>>>> function, I'd put that functionality in a C function, then write a
>>>> stap language wrapper for it. Something like the following (untested):
>>>>
>>>> ====
>>>> %{
>>>>
>>>> int internal_log_event(char *str)
>>>> {
>>>>     printk(KERN_INFO "name: %s\n", str);
>>>>     return 0;
>>>> }
>>>>
>>>> %}
>>>>
>>>> function log_event:long(str:string)
>>>> %{
>>>>     STAP_RETVALUE = internal_log_event(STAP_ARG_str);
>>>> %}
>>>>
>>>> function call_me()
>>>> {
>>>>     log_event("hello world")
>>>> }
>>>>
>>>> probe begin {
>>>>     call_me()
>>>> }
>>>> ====
>>>>
>>>> Note that the STAP_ARG_ function argument prefix and STAP_RETVALUE
>>>> item are documented and are supported.
>>>>
>>>> If this doesn't answer your question, you'll need to let us know what
>>>> you are really trying to do.
>>>>
>>>> --
>>>> David Smith
>>>> Principal Software Engineer
>>>> Red Hat

Re: Calling systemtap function from pure code

[David Smith]

On Thu, Sep 14, 2017 at 2:20 AM, Daniel Doron <danielmeirdoron@gmail.com> wrote:
> I will explain....
> i wanted to get as much info on kernel module insertion/removal but
> the init_module/delete_module probe points do not provide enough
> information. So , I thought about load_module() which does provide
> adequate info via struct module (local var),  but this gets filled
> along the way and I can;t really have access to it via systemtap. So I
> thought the simplest way to access that struct is though notification
> chain, i.e. use register_module_notifier() and extract the info from
> the struct there and then print it via systemtap.

I'd use the "module" set of tracepoints. The following is from a
RHEL6-era kernel:

====
# stap -L 'kernel.trace("module:*")'kernel.trace("module:module_free")
$mod:struct module*
kernel.trace("module:module_get") $mod:struct module* $ip:long
unsigned int $refcnt:int
kernel.trace("module:module_load") $mod:struct module*
kernel.trace("module:module_put") $mod:struct module* $ip:long
unsigned int $refcnt:int
kernel.trace("module:module_request") $name:char* $wait:bool $ip:long
unsigned int
====

As you can see, the "module_load" tracepoint that has the struct
module as an argument. So, you could do something like this:

====
probe kernel.trace("module:module_load")
{
    print($mod$)
}
====

> So I guess the right question would be how to access the STAP print
> function/mechanism/buffer...from standard kernel code.

Assuming you are in a stap kernel module, you can call _stp_printf(),
which has arguments like you'd expect. When you are finished printing,
you should call _stp_print_flush(). Now this interface isn't
guaranteed either, but I don't imagine we'll be changing it anytime
soon.

-- 
David Smith
Principal Software Engineer
Red Hat

Re: Calling systemtap function from pure code

[Daniel Doron]

Thanks David. Just what I need...

On Thu, Sep 14, 2017 at 5:57 PM, David Smith <dsmith@redhat.com> wrote:
> On Thu, Sep 14, 2017 at 2:20 AM, Daniel Doron <danielmeirdoron@gmail.com> wrote:
>> I will explain....
>> i wanted to get as much info on kernel module insertion/removal but
>> the init_module/delete_module probe points do not provide enough
>> information. So , I thought about load_module() which does provide
>> adequate info via struct module (local var),  but this gets filled
>> along the way and I can;t really have access to it via systemtap. So I
>> thought the simplest way to access that struct is though notification
>> chain, i.e. use register_module_notifier() and extract the info from
>> the struct there and then print it via systemtap.
>
> I'd use the "module" set of tracepoints. The following is from a
> RHEL6-era kernel:
>
> ====
> # stap -L 'kernel.trace("module:*")'kernel.trace("module:module_free")
> $mod:struct module*
> kernel.trace("module:module_get") $mod:struct module* $ip:long
> unsigned int $refcnt:int
> kernel.trace("module:module_load") $mod:struct module*
> kernel.trace("module:module_put") $mod:struct module* $ip:long
> unsigned int $refcnt:int
> kernel.trace("module:module_request") $name:char* $wait:bool $ip:long
> unsigned int
> ====
>
> As you can see, the "module_load" tracepoint that has the struct
> module as an argument. So, you could do something like this:
>
> ====
> probe kernel.trace("module:module_load")
> {
>     print($mod$)
> }
> ====
>
>> So I guess the right question would be how to access the STAP print
>> function/mechanism/buffer...from standard kernel code.
>
> Assuming you are in a stap kernel module, you can call _stp_printf(),
> which has arguments like you'd expect. When you are finished printing,
> you should call _stp_print_flush(). Now this interface isn't
> guaranteed either, but I don't imagine we'll be changing it anytime
> soon.
>
> --
> David Smith
> Principal Software Engineer
> Red Hat

Re: Calling systemtap function from pure code

[Frank Ch. Eigler]

Daniel Doron <danielmeirdoron@gmail.com> writes:

> Is it possible to call a stap function from [embedded-c code]?

> function log_evnt_stap(name){
>     printf("name %s \n", name )
> }
> [something like ... function foo () %{ log_event_stap("foo") %}

Nope.  For example, the code that systemtap functions are translated to
have a rather different API/ABI at the C level, e.g., involving putting
parameters into an explicit stack structure (context*).  You can
probably hack together something that would work for your script, based
on an examination of stap -p3 output, but is not a well-supported
technique.

- FChE