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]

[Bug translator/17040] New: Probing inline * at srcfile:line finds the wrong context


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.


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