This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Probing padzero problem


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]