This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Calling systemtap function from pure code


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]