From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27359 invoked by alias); 30 Aug 2011 16:38:47 -0000 Received: (qmail 26989 invoked by uid 22791); 30 Aug 2011 16:38:42 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 30 Aug 2011 16:38:22 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p7UGcLHc006647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 30 Aug 2011 12:38:21 -0400 Received: from [10.3.113.42] (ovpn-113-42.phx2.redhat.com [10.3.113.42]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p7UGcKKG023569; Tue, 30 Aug 2011 12:38:21 -0400 Message-ID: <4E5D11FC.8060009@redhat.com> Date: Tue, 30 Aug 2011 16:38:00 -0000 From: Josh Stone User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Dave Brolley CC: systemtap@sources.redhat.com Subject: Re: Does This Probe Make Sense? References: <4E5D03D3.4010208@redhat.com> In-Reply-To: <4E5D03D3.4010208@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2011-q3/txt/msg00230.txt.bz2 On 08/30/2011 08:37 AM, Dave Brolley wrote: > I ran across this while writing the unprivileged_all.exp test suite last > week. I was unable to create an example for which a probe of the form: > > process.function(ADDRESS).inline > > would resolve. It was suggested by fche that this probe didn't make much > sense to him in the first place. I would like to arrive at a definitive > answer. Does this probe make any sense and, if so, can someone provide > an example? Hmm, I found one: > $ stap -l 'process("stap").function("main")' > process("/usr/local/bin/stap").function("main@../main.cxx:935") > $ stap -l 'process("stap").function("main")' -vv |& grep pc= > probe main@../main.cxx:935 process=/usr/local/bin/stap reloc=.absolute pc=0x40d510 > $ stap -l 'process("stap").function(0x40d510).*' > process("/usr/local/bin/stap").function(0x40d510).call > process("/usr/local/bin/stap").function(0x40d510).return > $ stap -l 'process("stap").function(0x40d510).*' -vv |& grep pc= > probe main@../main.cxx:935 process=/usr/local/bin/stap reloc=.absolute pc=0x40d510 > probe main@../main.cxx:935 process=/usr/local/bin/stap reloc=.absolute pc=0x40d510 > $ stap -l 'process("stap").function(0x40d610).*' > process("/usr/local/bin/stap").function(0x40d610).inline > $ stap -l 'process("stap").function(0x40d610).*' -vv |& grep pc= > probe size@/usr/lib/gcc/x86_64-redhat-linux/4.6.0/../../../../include/c++/4.6.0/bits/stl_vector.h:570 process=/usr/local/bin/stap reloc=.absolute pc=0x40d5fd But I don't like that behavior, especially since the last one doesn't have any way to reach the containing function.call. Every PC address should have a .call and .return, and could be contained in one or more .inline nests as well. Since the inlines cause ambiguity, and may get in the way of reaching the .call, I think we should do away with this. So IMO, get rid of the .function(NUM).inline binding, and make sure that addresses in an inline still reach out to the containing .call. Josh