This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/17040] New: Probing inline * at srcfile:line finds the wrong context
- From: "jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Mon, 09 Jun 2014 18:18:17 +0000
- Subject: [Bug translator/17040] New: Probing inline * at srcfile:line finds the wrong context
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=17040
Bug ID: 17040
Summary: Probing inline *@srcfile:line finds the wrong context
Product: systemtap
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: translator
Assignee: systemtap at sourceware dot org
Reporter: jistone at redhat dot com
Call this PR10603's sequel. Probe addresses seem to be working better now, but
the probe context is incorrect. I'm on 3.14.5-200.fc20.x86_64 for these
examples.
Warming up:
$ stap -l 'kernel.function("__put_unused_fd")' --vp 02 |& grep pc=
probe __put_unused_fd@fs/file.c:522 kernel reloc=.dynamic pc=0xffffffff8120686c
probe __put_unused_fd@fs/file.c:522 kernel reloc=.dynamic pc=0xffffffff8120728a
probe __put_unused_fd@fs/file.c:522 kernel reloc=.dynamic pc=0xffffffff81207341
Try to probe fs/file.c:522 as a statement:
$ stap -l 'kernel.statement("*@fs/file.c:522")' --vp 02
Attempting to extract kernel debuginfo build ID from
/lib/modules/3.14.5-200.fc20.x86_64/build/vmlinux.id
focused on module 'kernel' = [0xffffffff81000000-0xffffffff8243e000, bias 0
file /usr/lib/debug/lib/modules/3.14.5-200.fc20.x86_64/vmlinux ELF machine
|x86_64 (code 62)
semantic error: no line records for fs/file.c:522 [man error::dwarf] (try :519
or :524)
thrown from: ../dwflpp.cxx:1764
semantic error: while resolving probe point: identifier 'kernel' at <input>:1:7
thrown from: ../elaborate.cxx:1056
source: probe kernel.statement("*@fs/file.c:522") {}
^
semantic error: no match
thrown from: ../elaborate.cxx:1019
This error actually seems fine. 522 is the declaration, and indeed 524 is the
first real statement.
522 static void __put_unused_fd(struct files_struct *files, unsigned int fd)
523 {
524 struct fdtable *fdt = files_fdtable(files);
525 __clear_open_fd(fd, fdt);
526 if (fd < files->next_fd)
527 files->next_fd = fd;
528 }
So let's try 524 as suggested:
$ stap -l 'kernel.statement("*@fs/file.c:524")' --vp 02 |& grep pc=
probe __close_fd@fs/file.c:524 kernel reloc=.dynamic pc=0xffffffff81207282
probe do_close_on_exec@fs/file.c:524 kernel reloc=.dynamic
pc=0xffffffff8120734b
probe put_unused_fd@fs/file.c:524 kernel reloc=.dynamic pc=0xffffffff81206868
We found three locations, not identical to the original function.inline, but
close enough that it's probably fine. However, the function context is wrong,
and the available variables follow along:
$ stap -L 'kernel.statement("*@fs/file.c:524")'
kernel.statement("__close_fd@fs/file.c:524") $files:struct files_struct*
$fd:unsigned int $file:struct file*
kernel.statement("do_close_on_exec@fs/file.c:524") $files:struct files_struct*
$i:unsigned int $fdt:struct fdtable*
kernel.statement("put_unused_fd@fs/file.c:524") $fd:unsigned int
Ideally, we should recover the __put_unused_fd function scope, with $files,
$fd, and maybe $fdt available. The variables are of course subject to
optimization, but we shouldn't see any others.
--
You are receiving this mail because:
You are the assignee for the bug.