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

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

On 9/15/17 10:05 AM, Freeman Zhang wrote:
> 
> 
> 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 :-(
> 

Now I know the unwelcome truth -- the nvme module inserted to the system
isn't the one I built.

	[root@200 zhangzy]# modinfo nvme
	filename:       /lib/modules/4.11.3/extra/mlnx-nvme/host/nvme.ko

	[root@200 zhangzy]# du -h
/lib/modules/4.11.3/extra/mlnx-nvme//host/nvme.ko


	56K     /lib/modules/4.11.3/extra/mlnx-nvme//host/nvme.ko

		[root@200 zhangzy]# du -h
/lib/modules/4.11.3/build/drivers/nvme/host/nvme.ko


	508K    /lib/modules/4.11.3/build/drivers/nvme/host/nvme.ko

After replaceing the out-of-tree modules with in-tree ones, I got
everything and probably want to lower opitimization level for more
information.


Thank you every much for your help!
Freeman