From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by sourceware.org (Postfix) with ESMTPS id 0DC023858D1E for ; Thu, 11 May 2023 19:28:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0DC023858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=serhei.io Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=serhei.io Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 0D1DC5C0259; Thu, 11 May 2023 15:28:11 -0400 (EDT) Received: from imap50 ([10.202.2.100]) by compute4.internal (MEProxy); Thu, 11 May 2023 15:28:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=serhei.io; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1683833291; x=1683919691; bh=W5 OwvHA++A0FxpE2wxFFcCW6YJty+Ny6nvHUYUNbUdk=; b=nYvanPgJD4HAiRwFAh 80OsDoF5hVEymGdmGxbmuGiI4pWrFGle3qINgPUnn9c1zy9waE8sUmofcdU48N86 MVyks+a0jutTmY7xU9NCk2t6oStBsMRmY8jvTt0MFGI+FqqjLTYzvJKUACGL+exG Vxamj7rTqskwCo6VdcTk+cIamdTJeZltj/FzFI9IljLg/ftfaNrQeoT5gb7ZuPo8 yhNGT5TNSzKkhXHOaAPA2gLPcg7MhjluOcLtrweyHXaJuU7pSn+tr7QWB49nGaTV 0z4HMcbIALtmE6yJnqMYVGoLtuff9TAOHBfy+k3ZpLt+wp+wMSQvqdOOErJMn6wg R7PQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1683833291; x=1683919691; bh=W5OwvHA++A0Fx pE2wxFFcCW6YJty+Ny6nvHUYUNbUdk=; b=Q6/A0LForV3Y4FO5+EMeA22/C7DfH 99HdFfsZSXAOF5py56Pd7RSW9zM56lhmDrpGHbnwed1R5Qj6okA8F9Pz1vTO27nS CB4VXe0N/ee7QH+WE4Ytxr3g91jfcU76QJXkamdP1wSsm0euWsSIw5+9oP13HMZU jSe9Zp2aQsQGlF/si6H/BTV8BYBdQfqNHwmJe5kniZwq0hbKQPDQZHpzhWazMt4q 3D0ILj9rFEkkfST8dQAt5mhYoFbkj6RNilj+qkBJ6gXB5sr/PFk3b3IQtL16DsPB PpmnnGId0T/1I/sEKbCf7u9s7YKviw6vjl6BGPZ5MCXW3dApRSd+U+ZEg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeegkedgudeflecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdfu vghrhhgvihcuofgrkhgrrhhovhdfuceoshgvrhhhvghisehsvghrhhgvihdrihhoqeenuc ggtffrrghtthgvrhhnpedvuefghfdttdfhtdekheffffetkedtveeiheetuedtuefhueet tdetieetteejleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehsvghrhhgvihesshgvrhhhvghirdhioh X-ME-Proxy: Feedback-ID: i572946fc:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 546771700168; Thu, 11 May 2023 15:28:10 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-415-gf2b17fe6c3-fm-20230503.001-gf2b17fe6 Mime-Version: 1.0 Message-Id: <5e4a77d5-43ec-4ecc-918f-b3dd0e830c4c@app.fastmail.com> In-Reply-To: References: <592158b9-d920-455d-8b2d-b4419c622929@app.fastmail.com> Date: Thu, 11 May 2023 15:27:50 -0400 From: "Serhei Makarov" To: "Christian Hergert" , builder--- Cc: "Frank Ch. Eigler" , "Mark Wielaard" Subject: Re: eu-stacktrace: roadmap and discussion thread Content-Type: text/plain X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, May 8, 2023, at 5:50 PM, Christian Hergert wrote: > First off, this all sounds great! > ... > > From a consumption standpoint, it would be nice if Sysprof could get a > perf stream where the PERF_SAMPLE_STACK are transparently converted to > PERF_SAMPLE_CALLCHAIN. I don't think eu-stacktrace necessarily needs to > speak Sysprof's capture API. >... > > Sysprof already contains `sysprofd` which can open the Perf event stream > for us via d-bus/CAP_SYS_ADMIN/polkit integration. After Sysprof gets > the perf FD back from sysprofd we could spawn eu-stacktrace giving it > the FD to consume and another FD to write the translated/passthrough events. The idea with sysprofd in the below quote sounds intriguing; I think we can experiment with it once we have some perf parser code of our own. For now, I'm satisfied with the fact that the patch to enable Sysprof to pipe data to eu-stacktrace is very small, and the parsing code I'm working on for separating out Sysprof capture frames is also quite small. Both are easy to adapt to any refactoring or even data format changes you might happen to do. > Sysprof can do offline symbolizing of frames which is somewhat important > when trying to analyze profiles from an embedded device, a machine that > is disk/network constrained, or end-user-system via bug reports. We can > fairly trivially teach Sysprof to do symbolizing via debuginfod. Yep -- and that could be a separate patchset, since the current approach I'm using changes nothing about the Sysprof symbolizing phase. > In the case you're describing, is it right that you may not be able to > unwind stack frames without debuginfod because there was no way to > locate the `.eh_frame` section for the binary? Yep -- for containers, I considered debuginfod as a possible fallback if the .eh_frame data isn't accessible on the local filesystem. Of course that doesn't work for non-packaged container programs, unless the developers of those programs set up debuginfod. In general the workflows for debuginfo on containers are rather under-developed. Honestly this isn't a scenario to implement as a first priority, but I do want to keep track of everything that's required to have sysprof+eu_stacktrace+eh_frame+PERF_SAMPLE_STACK maintain feature parity with sysprof+-fno-omit-fp+PERF_SAMPLE_CALLCHAIN. Thus I am making sure to list such consideration. > The code to do the mount namespace conversion is quite terrible in > Sysprof and even now I'm in the midst of cleaning it up. We have to both > create a "view" of the namespace as it was to the PID as well as a way > to convert that view into something the mount namespace analyzing the > capture file might be able to open. Any of these may or may not be in a > rootless container (toolbox/podman/flatpak/etc). > > Whether or not this is something we can eventually contain inside of > bubblewrap is another can of worms. One possible solution.... For this type of situation, we could perhaps give eu-stacktrace an optional dependency on sysprof-devel. Right now, I rely on sysprof-capture-types.h but that's just the header and therefore not a runtime dependency. When the sysprof libraries are available, we could also use sysprof's mount namespace conversion code (in whatever eventual form it takes) to get .eh_frame data.