This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Why 'stap -L' shows no variables in some modules?
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?
'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
---
>> # how can I access the local vars when 'stap -L' gives no local vars?
>>
>> 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?