Re: Suggestions for localizing problems with identifiers in SystemTap.

[Roland McGrath <roland at redhat dot com>]

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