From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <systemtap-return-13067-listarch-systemtap=sources.redhat.com@sourceware.org>
Received: (qmail 12050 invoked by alias); 28 Jul 2009 13:32:44 -0000
Received: (qmail 12002 invoked by uid 48); 28 Jul 2009 13:32:32 -0000
Date: Tue, 28 Jul 2009 13:32:00 -0000
From: "mjw at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: systemtap@sources.redhat.com
Message-ID: <20090728133231.10454.mjw@redhat.com>
Reply-To: sourceware-bugzilla@sourceware.org
Subject: [Bug translator/10454] New: Raw number statement probes won't work without dwarf info
X-Bugzilla-Reason: AssignedTo
Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <systemtap.sourceware.org>
List-Subscribe: <mailto:systemtap-subscribe@sourceware.org>
List-Post: <mailto:systemtap@sourceware.org>
List-Help: <mailto:systemtap-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: systemtap-owner@sourceware.org
X-SW-Source: 2009-q3/txt/msg00218.txt.bz2

Something like the following on a function without dwarf info won't work:

$ nm /lib64/libpthread-2.10.1.so | grep -w __lll_lock_wait
00000030ac20d910 t __lll_lock_wait

$ stap -d /lib64/libpthread-2.10.1.so -g -e 'probe
process("/lib64/libpthread-2.10.1.so").statement(0x00000030ac20d910) { log
("__lll_lock_wait called"); }'

Note that we need to use -g otherwise we get:

semantic error: address 0x30ac20d910 does not match the beginning of a statement
(no line info found for '../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S',
in module '/lib64/libpthread-2.10.1.so')

We hit this part of tapsets.cxx (query_cu):

          // Verify that a raw address matches the beginning of a
          // statement. This is a somewhat lame check that the address
          // is at the start of an assembly instruction.  Mark probes are in the
          // middle of a macro and thus not strictly at a statement beginning.
          // Guru mode may override this check.

It might be an idea to allow "misplaced statement expressions" for user space
probes always since it isn't very "dangerous". Also note that "assembly
instruction" isn't really what is being tested. It is really whether there is
dwarf line info that says the statement given starts on a line.

Given guru mode, the next part of query_cu () then calls
dwlpp.iterate_over_functions(), with query_dwarf_func() as callback.
query_dwarf_func() will then populate the dwarf_query filtered_functions vector.
But since there is no dwarf info for the covered statement, the dwarf_query
callback is never called, so filtered_functions stays empty.

So this last part of query_cu() "// Otherwise, simply probe all resolved
functions." will not call query_func_info () so query_statement () is also never
called, so no probe will be registered.

-- 
           Summary: Raw number statement probes won't work without dwarf
                    info
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: mjw at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=10454

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.