From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66621 invoked by alias); 13 Jan 2020 05:28:33 -0000 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 Received: (qmail 66610 invoked by uid 89); 13 Jan 2020 05:28:32 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=capability, monitor, subset, inclusion X-HELO: mail-lf1-f52.google.com Received: from mail-lf1-f52.google.com (HELO mail-lf1-f52.google.com) (209.85.167.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 13 Jan 2020 05:28:30 +0000 Received: by mail-lf1-f52.google.com with SMTP id r14so5879009lfm.5 for ; Sun, 12 Jan 2020 21:28:30 -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=+Yslrwgbp2NqpUh5M/Y0q0G764huJC9vY+L9Tcc90iM=; b=F8O/VH4tBd0f8UutYP9/UMD8QCqrmOn1FaHfJXSTI1+6TijWBNexa8kHqW8mUwlgxz z/OfTe43XiIDLiSFK3BZDcTZq0B7XHjq0SjbgTPHuCWyGG99yt+xQNqFSpT4ssu1WCfy 4OQLKf6JQXczchuMKWCqZMMbQwnFkrs+0AAXbDuGeRM4PcPnpHLXz564ARgmNUg+lhVY +Qg3T5a4YtZKYBOLNwnYiVfmJBq36kbuw1FLjMC2FdpvebCE/9Uj4dkzYty0UBVS9J8G HLOI1L+qGwI0lQ9Bx5DMEnDWvPgUHV5aJOXuoijKal7I1PvUZ8bCwketraAoNPlACTgJ XhDg== MIME-Version: 1.0 References: <87blrcfox9.fsf@redhat.com> In-Reply-To: <87blrcfox9.fsf@redhat.com> From: Craig Ringer Date: Mon, 13 Jan 2020 05:28:00 -0000 Message-ID: Subject: Re: SDTs with data types and argument names To: "Frank Ch. Eigler" Cc: systemtap@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2020-q1/txt/msg00005.txt On Fri, 10 Jan 2020 at 02:46, Frank Ch. Eigler wrote: > > It'd be great to capture the probe argument names and their data types to > > systemtap when SDTs are generated from a probes.d file. It'd make sense > to > > expose this capability for when probes are defined with STAP_PROBE(...) > etc > > in their own builds too. > > Yeah. I believe there was a kernel-bpf-oriented group last year, who > were speculating extending sdt.h in a similarly motivated way. > Good to know. Any idea who may've been involved? It'd be good to collaborate and not duplicate work or explore a dead-end already followed. > > The goal is to let you write > > > > probe process("myapp").mark("some__tracepoint") > > { > > printf("hit some__tracepoint(%s, %d)\n", > > user_string(useful_firstarg_name), > > some_secondarg->somemember->somelongmember); > > } > > and display useful arg names and types in `stap -L` too. > > Note that one point of the sdt.h structure was to make the executables > self-sufficient with respect to extracting this data, even if there is > no debuginfo available. Adding type names can only work if that > debuginfo is available after all, or else if it's synthetically > generated via @cast("") type constructs. > Indeed. And the latter option is hairy for complex and portable software: you must get exactly the right header version, but you must also ensure you have any number of preprocessor macros etc set precisely the same. There can be header inclusion order considerations and more. I'm very reluctant to use the automated header processing features. Without debuginfo we'd still get useful probe names, which would IMO be exceedingly useful. stap could expose them as $theArgName and still expose them as $arg1 etc for BC, so that wouldn't upset anyone. It might also let stap handle narrower integer types better. And *if* debuginfo was present, it could allow the user to traverse structs etc via $theArgName->member->foo . I don't know of any way to ask gcc/gdb/binutils/etc to retain a subset of debuginfo in an executable when it's being stripped, and I doubt that'd be popular or accepted anyway. Where would you stop? In many cases the immediate struct would be of little value without type info for its member types and their member types and so on. So I realise that it's no substitute for debuginfo, and doesn't make it possible to get full functionality without it. What it _should_ do is put static probes on an equal footing with DWARF probes when debuginfo is present. Right now they're inferior in quite a number of ways: no argument names, no argument types without explicit and verbose casting, representations in monitor mode are hex statement positions not probe names, and more. > Saving the argument names looks relatively simple in most cases. Define an > > additional set of macros in the usual STAP_PROBE2() etc style like the > > following pseudoishcode: > > > > STAP_PROBE2_ARGAMES(provider, probename, argname1, argname2) \ > > const char "__stap_argnames_" ## provider ## "_" ## probename ## > > [2][] \ > > = { #argname1, #argname2 } \ > > __attribute__ ((unused)) \ > > __attribute__ ((section (".probes"))); > > > > i.e generate some constant data with the probe names in a global array we > > can look up when compiling the tapscript based on the provider and probe > > name. > > Yeah, that's a sensible way of doing it, without creating a new note > format or anything. It's important that the section be marked with > attributes that will force it to be pulled into the main executable > via the usual linker scripts. > I'll look into that. This won't be something I can leap to do in a hurry as I have to fit it in bits and pieces around main deliverables. I'm sure you know the feeling. But I'm keen to work on it when I get the chance. -- Craig Ringer http://www.2ndQuadrant.com/ 2ndQuadrant - PostgreSQL Solutions for the Enterprise