From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) by sourceware.org (Postfix) with ESMTPS id C5104386100B for ; Thu, 21 Jan 2021 05:47:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C5104386100B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=2ndquadrant.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=craig.ringer@2ndquadrant.com Received: by mail-lj1-x231.google.com with SMTP id u21so1163265lja.0 for ; Wed, 20 Jan 2021 21:47:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RnnJDQp3jSPWLMFOkK6Dk8k3uDaAYOVrTNBQup99IxQ=; b=Z3FudWoiDDGnOn1fPswQdrQZ3bPSZol1M3afa+1RQBFaRCT2kp6q5xjnzZPX6sJl8a 0si863imTTbe5qbmy4UPV+//bwo40NdyuY62yYLh1uZi3StGbZC+Jg8aNzmheixq6e0I 7ssgop4ymtckLzzWzScpH3v0FXNWzCDnNhQFJZ443xm2RyoJcohMJogSujk5smlMdG44 8VXKwuCsXxreAcAfQSSJFw5oRpXrJ0QN48c/dVbbMG1vNlcn6oGSPE0xNveDoNKKvn+t LriYXIRhDPr+dfpk6x835zg/nbBsiLyL2fdqs0tDpo0iv0ff/PugJ4Z5rH4yr/iyby82 4YJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RnnJDQp3jSPWLMFOkK6Dk8k3uDaAYOVrTNBQup99IxQ=; b=bNm/TAR0P+1/OhXkRembJRAX0QN+9sPnt60/CGFHOXHD8kraN0p/zNlEFqhQWjxaYy jWeZvx9E9Ra/L5PwoLVHpFBaqY3MUGdMZ6abnZ75JqLVPPZ2a4K6D5eYGg9D+hWa1tzx c047hfyV85GuE/yJhBJMbv3F0rJIcG93XK/Tjt7+QoC0fGraxBoeI/fZdiLUfIqPJ0+8 4RvVIFFFParIg32CMW3zVbrljkT0c0GJjnWIomqhSs/Tzg1BrR5iyE8Z62hEtCRD0zV9 SMdd9EqZ9i+RBBN/Fj+SfeW9gepLQ2ZRENQEbSYo4kq7n4IQiOuw5QGC4VY1VU9LhmjA Tqkg== X-Gm-Message-State: AOAM530EOTsU/ZKh6AoiglNrYI+0T1n4Jb4Y0rWwKts/J0ClJlxUuyhh 80ndeSnvMdVpJNJOt7+4afMKRUk6uwemPcrPGsP0TOk0tun1AuS1 X-Google-Smtp-Source: ABdhPJyRnZthkffpiGER7fnUnDOPrnGIXNPSWZ6lxhQsHP4DuvIw9y8SYTm9fXnwQOxUbzpNNXFwijfNioa43KZ+Hso= X-Received: by 2002:a05:651c:1254:: with SMTP id h20mr5990712ljh.211.1611208031603; Wed, 20 Jan 2021 21:47:11 -0800 (PST) MIME-Version: 1.0 References: <7de6169c-2235-4022-6fad-f07f0edadfa0@redhat.com> In-Reply-To: <7de6169c-2235-4022-6fad-f07f0edadfa0@redhat.com> From: Craig Ringer Date: Thu, 21 Jan 2021 13:47:00 +0800 Message-ID: Subject: Re: Emitting marker names instead of hex statement addresses for SDT probes? To: Stan Cox Cc: systemtap@sourceware.org, "Frank Ch. Eigler" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: systemtap@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Systemtap mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2021 05:47:15 -0000 On Wed, 20 Jan 2021 at 06:21, Stan Cox wrote: > If I use --dyninst (which creates a probe source that is easy to modify > and rebuild to try quick experiments) then this change forces the probe > point name: > #define STP_NEED_PROBE_NAME=1 > changed in enter_dyninst_uprobe: > c->probe_point = sup->probe->pn; /* was ->pp */ > > % stapdyn *.so -c /work/scox/stap/sdt/tstclass.x > process("/work/scox/stap/sdt/tstclass.x").mark("test_probe_4") aa=0xa > string1=abc > 10 20 abc xyz > 10 20 abc xyz > > (where the original probe was doing: printf("%s aa=%#lx > string1=%s\n",pp(),@cast($arg1,"struct A")->aa, ...) > Thanks so much for having a go! I've since gone in circles in the C++ stap code trying to work out where the generated probe name comes from. I can confirm that c->probe_name contains what I want pp() to emit, and c->probe_point contains the statement. After some diversions through the DWARF code and various other places I landed up at case uprobe3_type: // process("executable").statement(probe_arg) derived_comps.push_back (new probe_point::component(TOK_STATEMENT, new literal_number(pc, true))); break; since it appears that a userspace SDT "process("foo").mark("bar")" is a uprobe3_type: matched probe_name test_marker probe type uprobe3 at 0x40110a probe_type == uprobe3, use statement addr: 0x40110a ... symbol resolution for derived-probe probe process("/home/craig/projects/2Q/systemtap/test_sdt").statement(0x40110a){ printf("probe_point is \"%s\"\\n", %{ /* string */ c->probe_point %}); } AFAICS the issue may be that the marker in pp_mark for sdt_query::convert_location() could be a wildcard so a statement address was used to disambiguate. This is already supposed to work. // replace the possibly wildcarded arg with the specific marker name *it = new probe_point::component(TOK_MARK, new literal_string(probe_name)); but doesn't appear to affect the printed probe specific name. If I jam some code into convert_location() clog << "SPECIFIC NAME: " << specific_loc->str() << endl; clog << "BASE PROBE: " << base_loc->str() << endl; I see output SPECIFIC NAME: process("/home/craig/projects/2Q/systemtap/test_sdt").mark("test_marker") BASE PROBE: process("test_sdt").mark("test_marker") which is what I expect, but somehow that doesn't translate into the final probe_name. see test script: probe process("test_sdt").mark("test_marker") { printf("probe_point is \"%s\"\n", %{ /* string */ c->probe_point %} ); } and source file #include int main() { DTRACE_PROBE(dummy,test_marker); return 0; } Also I keep Since someone went to the effort of implementing STP_NEED_PROBE_NAME I expect we should care about it. The probe names should be strings in read-only ELF sections so memory use shouldn't be a concern though, it'd only affect binary size. If they *aren't* in rodata, that's worth fixing. It's not clear how much we should really care about the size of these strings in the .ko. The original commit says "Add pp1 to stap_probe, predicated on STP_NEED_PROBE_POINT_LISTING so we don't waste space." That was later renamed to pp() and STP_NEED_PROBE_NAME. There's no detail on why the space matters. The relevant commits appear to be dc575eac0, d48df0cfe, 2d767770c . I didn't want to force PROBE_NAME to be defined in this case since I don't think there's a good reason that probe_point should have the "statement()" form when we could emit the "mark()" form consistently. On a side note, I was looking for how to get error() to emit the current file and line number from the tapset but drew a blank on that. I can see that the various visitors have access to a token (tok) with location member containing file and line info and that there's a mechanism for visitors to prepend bits of code, so I assume it'd be possible to transform references to "@__FILE__" and "@__LINE__" in stap code into the appropriate constants with one of the various walker visitors, but I'm wondering if its feasible to do so at the macro processing level to keep it simpler. -- Craig Ringer http://www.2ndQuadrant.com/ 2ndQuadrant - PostgreSQL Solutions for the Enterprise