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

[Freeman Zhang <freeman dot zhang1992 at gmail dot com>]

On 9/15/17 2:06 AM, David Smith wrote:
> 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.
> 

No, it doesn't work either for nvme module while for other modules it
does strip some function calls like you said.

The problem is that I don't see anything special in nvme codes as well
as its Makefile and output of eu_readelf. If it's for optimization
matter, other modules shouldn't have printed any variable either but in
fact they do -- it's just nvme that refuses to print :-(

>>>> 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.
>