Re: Calling systemtap function from pure code

[Daniel Doron <danielmeirdoron at gmail dot com>]

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