| Summary: | Inlines don't match filenames correctly | ||
|---|---|---|---|
| Product: | systemtap | Reporter: | Josh Stone <jistone> |
| Component: | translator | Assignee: | Unassigned <systemtap> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
I've been refactoring our dwarf code recently, and I think I've tracked down what's happening here. For each compilation unit, we're matching the file pattern against all of the files in that CU. If there are any matches, then we proceed to search the entire CU for the function pattern. So in the OP, stap found every CU that happened to include "include/linux/mm.h", and then probed all inline instances in those CUs, regardless of where each inline was defined. We'll probably just have to match the decl_file against the pattern again for each candidate function... Fixed in commit bd25380, PR2475: Filter filenames against the decl_file All listed functions are now from the correct file: $ ./run-stap -l 'kernel.function("*@include/linux/mm.h").inline' kernel.function("lowmem_page_address@include/linux/mm.h:605").inline kernel.function("init_page_count@include/linux/mm.h:328").inline kernel.function("page_mapped@include/linux/mm.h:696").inline kernel.function("pgtable_page_dtor@include/linux/mm.h:973").inline kernel.function("pgtable_page_ctor@include/linux/mm.h:967").inline kernel.function("get_page@include/linux/mm.h:311").inline kernel.function("compound_head@include/linux/mm.h:299").inline kernel.function("page_count@include/linux/mm.h:306").inline kernel.function("pud_alloc@include/linux/mm.h:932").inline kernel.function("pmd_alloc@include/linux/mm.h:938").inline kernel.function("get_unmapped_area@include/linux/mm.h:1150").inline kernel.function("vma_pages@include/linux/mm.h:1241").inline kernel.function("page_zone@include/linux/mm.h:549").inline kernel.function("page_to_nid@include/linux/mm.h:543").inline kernel.function("zone_to_nid@include/linux/mm.h:531").inline kernel.function("get_page_unless_zero@include/linux/mm.h:273").inline kernel.function("page_mapping@include/linux/mm.h:647").inline kernel.function("put_page_testzero@include/linux/mm.h:263").inline kernel.function("set_compound_order@include/linux/mm.h:363").inline kernel.function("page_zone_id@include/linux/mm.h:526").inline kernel.function("page_mapcount@include/linux/mm.h:688").inline kernel.function("set_compound_page_dtor@include/linux/mm.h:345").inline kernel.function("compound_order@include/linux/mm.h:356").inline kernel.function("page_index@include/linux/mm.h:671").inline kernel.function("vma_nonlinear_insert@include/linux/mm.h:1102").inline kernel.function("round_hint_to_min@include/linux/mm.h:591").inline kernel.function("find_vma_intersection@include/linux/mm.h:1232").inline kernel.function("PageAnon@include/linux/mm.h:662").inline kernel.function("reset_page_mapcount@include/linux/mm.h:683").inline kernel.function("do_mmap@include/linux/mm.h:1163").inline |
Consider a probe like this: probe kernel.inline("*@include/linux/mm.h") The expected behavior is that this would probe all instances of inlines defined within "include/linux/mm.h". However, on i686 2.6.9-34.ELsmp, this actually matches the following set: static struct kprobe dwarf_kprobe_4[17688]= { {.addr= (void *) 0xc0100566}, {.addr= (void *) 0xc01005ac}, {.addr= (void *) 0xc01005e1}, {.addr= (void *) 0xc01005e6}, {.addr= (void *) 0xc01005fc}, ... }; char const * dwarf_kprobe_0_location_names[17688] = { "kernel.inline(\"unlock_kernel@include/linux/smp_lock.h:53\")", "kernel.inline(\"execve@include/asm/unistd.h:437\")", "kernel.inline(\"get_current@include/asm/current.h:9\")", "kernel.inline(\"get_current@include/asm/current.h:9\")", "kernel.inline(\"fixup_cpu_present_map@init/main.c:761\")", ... }; At first glance I thought that this was all instances of inlines *used* within the given file. However, it seems suspicious that execve would be called from within mm.h. Closer inspection of the matching address (0xc01005ac) shows that this probe point is the execve call within "run_init_process" in "init/main.c". In fact, all of the addresses from the exerpt above are from "init/main.c", and have no obvious tie to "include/linux/mm.h". So it appears that filename matching for inlines is completely broken... See also this thread: http://sources.redhat.com/ml/systemtap/2006-q1/msg00817.html