From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22548 invoked by alias); 5 May 2012 06:42:14 -0000 Received: (qmail 22540 invoked by uid 22791); 5 May 2012 06:42:13 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,TW_BJ,T_RP_MATCHES_RCVD 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; Sat, 05 May 2012 06:41:55 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q456ftZB016855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 5 May 2012 02:41:55 -0400 Received: from psique ([10.3.112.12]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q456foYo011916; Sat, 5 May 2012 02:41:52 -0400 From: Sergio Durigan Junior To: Jan Kratochvil Cc: gdb@sourceware.org Subject: Modify stap-probe.h to identify SystemTap probes References: <20120504152129.GA7418@redhat.com> <20120505060312.GA7019@host2.jankratochvil.net> <20120505062315.GA7458@host2.jankratochvil.net> X-URL: http://www.redhat.com Date: Sat, 05 May 2012 06:42:00 -0000 In-Reply-To: <20120505062315.GA7458@host2.jankratochvil.net> (Jan Kratochvil's message of "Sat, 5 May 2012 08:23:15 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00016.txt.bz2 [Moving to @gdb...] On Saturday, May 05 2012, Jan Kratochvil wrote: > On Sat, 05 May 2012 08:10:55 +0200, Sergio Durigan Junior wrote: >> On Saturday, May 05 2012, Jan Kratochvil wrote: >> > There is that >> > gdb_assert (probe_generic->pops == &stap_probe_ops); >> > >> > for this purpose. >> >> Which can only be used inside stap-probe.c. > > Why? stap_probe_ops can be made extern-public in stap-probe.h if there is now > a need for it. Which is equivalent to create the method that I propose, that would only validate a probe according to its ->probe_ops field, right? TBH, I think it's more clear to declare a method responsible for this "validation" instead of exporting stap_probe_ops to the public. > But in general there should never be such backend-specific conditional, the > virtualization makes no sense in such case at all. I don't think such conditional would invalidate the virtualization we made. Sometimes it is necessary to know which probe we have, for example in the case of exception/longjmp probes, which require SystemTap specific probes. Today, those cases are implemented because (a) we only support stap probes, so there's no way we would catch another probe type when filtering, and (b) because glibc/libgcc only have SystemTap probes. But it would be more correct if we checked the type of the probe(s) extracted from those objfiles to make sure we're dealing with SystemTap probes, and not with another probe type. > If the current probe.h interface is insufficient then it should be extended. I agree, but that's not the case. `probe.h' is sufficient, but it is not its responsibility to tell if a probe foo is a SystemTap probe. I see that it is a stap-probe.c-specific task. Sorry for keep pushing this subject, but I still think we should have a way of differentiating between probes' types. BTW, I already have a patch for that, but I won't send it yet because I want to see how this discussion goes... Thanks, -- Sergio