This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Suggestions for localizing problems with identifiers in SystemTap.
- From: Roland McGrath <roland at redhat dot com>
- To: "systemtap at sources dot redhat dot com" <systemtap at sources dot redhat dot com>
- Date: Sun, 26 Feb 2006 20:40:39 -0800 (PST)
- Subject: Re: Suggestions for localizing problems with identifiers in SystemTap.
The place I would start is with the "loc2c-test" program. This is a simple
test program built during the systemtap build, but not installed. It uses
exactly the same infrastructure for finding and interpreting the debug
information to identify variables at requested source locations.
loc2c-test takes some standard options (see --help), which are the same as
you can use with e.g. eu-addr2line. Use the -k option to look at the
current kernel and modules, the same way the systemtap translator does.
(The other options make it easy to look at info for different kernels.)
The required argument is an address constant, giving the PC location of the
probe. The -v output from stap should tell you this.
./loc2c-test -k 0xc012c9b1
This yields:
kernel/pid.c (0x11)
current_stack_pointer [2e9735] long unsigned int
pid_hash [2e9752] hlist_head*[]
pidhash_shift [2e9763] int
pidmap_array [2e9784] pidmap_t[]
pidmap_lock [2e9795] spinlock_t
__kcrctab_find_task_by_pid_type[2e97a6] long unsigned int const
__kstrtab_find_task_by_pid_type[2e97c7] char[] const
__ksymtab_find_task_by_pid_type[2e97dd] kernel_symbol const
console_printk [2e97f9] int[]
mmu_cr4_features [2e9806] long unsigned int
xtime [2e9813] timespec
time_status [2e9820] int
time_maxerror [2e982d] long int
time_esterror [2e983a] long int
time_adjust [2e9847] long int
contig_page_data [2e9854] pglist_data
malloc_sizes [2e986d] cache_sizes[]
last_pid [2e987a] int
init_task [2e988c] task_struct
irq_desc [2e98aa] irq_desc_t[]
irq_vector [2e98c7] u8[]
io_apic_irqs [2e98d4] long unsigned int
per_cpu__rcu_data [2e98e1] rcu_data
per_cpu__rcu_bh_data [2e98ee] rcu_data
rcu_ctrlblk [2e98fb] rcu_ctrlblk
rcu_bh_ctrlblk [2e9908] rcu_ctrlblk
dcache_lock [2e9915] spinlock_t
acpi_noirq [2e9922] int
acpi_disabled [2e992f] int
acpi_ht [2e993c] int
acpi_pci_disabled [2e9949] int
skip_ioapic_setup [2e9956] int
zone_table [2e996e] zone*[]
mem_map [2e997c] page*
swapper_space [2e998a] address_space
per_cpu__cpu_gdt_table [2e99a8] desc_struct[]
default_ldt [2e99c0] desc_struct[]
dma_spin_lock [2e99cd] spinlock_t
nr_kernel_pages [2e99da] long unsigned int
pid_max [2e99e7] int
pid_max_min [2e99f9] int
pid_max_max [2e9a0b] int
__crc_find_task_by_pid_type [2e9a1d] <no type>*
detach_pid (0x2e): 0xc012c9b1 (kernel/pid.c:193) .. 0xc012c9ed (kernel/pid.c:208)
task [2e9436] task_t*
type [2e9445] pid_type
tmp [2e9454] int
nr [2e9463] int
The shows the DWARF scopes that contain the PC address for the probe point,
and the variable names defined in each. Here you see the file (global)
scope, and inside it the "detach_pid" function scope. If a variable is not
shown here, then it wasn't found in the DWARF info. You can use readelf or
eu-readelf to investigate something you find missing here.
Thanks,
Roland