Re: Why 'stap -L' shows no variables in some modules?

[David Smith <dsmith at redhat dot com>]

On Thu, Sep 14, 2017 at 11:31 AM, Freeman Zhang
<freeman.zhang1992@gmail.com> wrote:
> Hi David
>
> Thanks for your reply!
>
> On 9/15/17 12:05 AM, David Smith wrote:
>>>
>>> #I wonder why they print differently? What determines whether 'stap -L'
>>> shows local vars or not?
>>
>> There are several factors that determine whether stap can find
>> parameters and local variables. The compiler you use, the quality of
>> its debuginfo, and the level of optimization are the biggest issues.
>> In the case of local variables, with a sufficiently high optimization
>> level, the compiler may have completely optimized the variable away so
>> it never existed.
>>
>> In the case of the nvme module itself, on my distro kernel I certainly
>> see parameters with 'stap -L' (and perhaps local variables too, I
>> didn't check).
>>
>> I'd make sure the nvme module has debuginfo. There are probably
>> several ways of doing this, the easiest might be using 'eu-readelf
>> -w'.
>>
>
> I would like to lower the optimization level but I heard there would be
> bunches of problems. Does this mean I'll never get access to local
> variables?

It depends on your compiler.

> 'eu-readelf -w nvme.ko' print something like:
>
> ---
>
> ➜  linux-4.11.3 eu-readelf -w drivers/nvme/host/nvme.ko | head
> DWARF section [32] '.debug_aranges' at offset 0x6ddc:
> Table at offset 0:
>  Length:            92
>  DWARF version:      2
>  CU offset:          0
>  Address size:       8
>  Segment size:       0
>
> ➜  linux-4.11.3 eu-readelf -w drivers/nvme/host/nvme.ko | tail
> <nvme_queue_rq+0x297>...text+0x00000000000031cf <nvme_queue_rq+0x29f>
>  [  1d00]  .text+000000000000000000
> <nvme_admin_exit_hctx>...text.unlikely+000000000000000000
> <dma_unmap_sg_attrs.part.37>
>            .text.unlikely+000000000000000000
> <dma_unmap_sg_attrs.part.37>...init.text+000000000000000000 <init_module>
>            .init.text+000000000000000000
> <init_module>...exit.text+000000000000000000 <cleanup_module>
>            .exit.text+000000000000000000
> <cleanup_module>...exit.text+0x000000000000001e
>
> ---

From what I can see, the above looks fairly reasonable.

>>> # how can I access the local vars when 'stap -L' gives no local vars?

Let's try something else here, try the following:

# stap -L 'module("nvme").function("*").call'

That should ignore inlined function calls, and should give you
parameter information.

>>> FYI: The kernel I use is 4.11.3 and is built by myself. I think it's
>>> with debuginfo because I turned on the CONFIG_DEBUG_INFO stuff and got a
>>> 159MB vmlinux. GDB also gave me positive response loading symbols from
>>> vmlinux and ko files. And the systemtap was built from the updated git
>>> repo.
>>
>> You might show us the output of:
>>
>> $ grep DEBUG_INFO .config
>>
>> Make sure CONFIG_DEBUG_INFO_SPLIT isn't on.
>>
>
>
>         ➜  linux-4.11.3 grep DEBUG_INFO .config
>         CONFIG_DEBUG_INFO=y
>         # CONFIG_DEBUG_INFO_REDUCED is not set
>         # CONFIG_DEBUG_INFO_SPLIT is not set
>         # CONFIG_DEBUG_INFO_DWARF4 is not set
>
> Is there any problem?

Nope, that looks fairly reasonable.

-- 
David Smith
Principal Software Engineer
Red Hat