This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Probing padzero problem
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: "Paddie O'Brien" <paddieobrien at gmail dot com>
- Cc: systemtap <systemtap at sourceware dot org>
- Date: Tue, 06 Sep 2016 11:34:53 -0400
- Subject: Re: Probing padzero problem
- Authentication-results: sourceware.org; auth=none
- References: <CAOK12Db-ZjSN8=+xHqzgAvv1q_hH6gyRinZ-9QaaoNed4PE8Hg@mail.gmail.com>
paddieobrien wrote:
> [...]
> # stap -L 'kernel.function("padzero")'
> kernel.function("padzero@fs/binfmt_elf.c:113") $elf_bss:long unsigned int
> But when I try to probe it with:
> probe kernel.function("padzero@fs/binfmt_elf.c:113")
> [...]=
> WARNING: For probing a particular line, use a .statement() probe, not .function
> semantic error: no line records for fs/binfmt_elf.c:113 [man error::dwarf] (try
Sorry, systemtap is misleading you. tl;dr: use instead: probe
kernel.function("padzero") { }
Systemtap accepts filename:linenumber suffixes for function probes,
but sort of reluctantly, as an ambiguity resolution tool. People have
confused .statement() and .function() probes many times in the past,
so the warning is there to nudge them away.
It prints the function's declaration file:line in the "stap -l" report
and elsewhere. But it doesn't compare incoming file:line values
against the declarations, only against (statement-oriented) line
records. Thus it doesn't find a match (because there is no statement
on that first declaration line), and gives the silly error.
Systemtap should perhaps not list the file:line number in stap -l output.
Systemtap should definitely accept the declaration file:line suffix for
a function probe.
- FChE