From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dd14210.kasserver.com (dd14210.kasserver.com [85.13.138.83]) by sourceware.org (Postfix) with ESMTPS id B93213858D28 for ; Fri, 8 Apr 2022 19:50:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B93213858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=milianw.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=milianw.de Received: from milian-workstation.localnet (p54a1bbed.dip0.t-ipconnect.de [84.161.187.237]) by dd14210.kasserver.com (Postfix) with ESMTPSA id AC16824023A; Fri, 8 Apr 2022 21:50:18 +0200 (CEST) From: Milian Wolff To: "Frank Ch. Eigler" Cc: elfutils-devel@sourceware.org Subject: Re: Questions regarding debuginfod.h API Date: Fri, 08 Apr 2022 21:50:18 +0200 Message-ID: <15044726.Ck1BFTr2H8@milian-workstation> In-Reply-To: <20220408194432.GB23295@redhat.com> References: <5817622.lOV4Wx5bFT@agathemoarbauer> <12359040.Dq0kRfdbeh@milian-workstation> <20220408194432.GB23295@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3109949.FXb7mknhcm"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2022 19:50:21 -0000 --nextPart3109949.FXb7mknhcm Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii"; protected-headers="v1" From: Milian Wolff To: "Frank Ch. Eigler" Cc: elfutils-devel@sourceware.org Subject: Re: Questions regarding debuginfod.h API Date: Fri, 08 Apr 2022 21:50:18 +0200 Message-ID: <15044726.Ck1BFTr2H8@milian-workstation> In-Reply-To: <20220408194432.GB23295@redhat.com> On Freitag, 8. April 2022 21:44:32 CEST Frank Ch. Eigler wrote: > Hi - > > > > (See also the DEBUGINFOD_MAXTIME and DEBUGINFOD_MAXSIZE env vars > > > that can limit this.) > > > > I did come across those, but what are suggested best practices in > > setting those? When using GDB or a profiler on larger non-trivial UI > > applications on Linux for the first time, we would start to download > > dozens of debug packages, taking hundreds of megabytes of > > space. [...] > > Yes, and each of those downloads can be limited by these criteria. An > application such as gdb could adds its own throttling on top, if it is > going to do a long series of downloads. (Alternately, gdb can try not > to download all this stuff early; we're investigating gdbindex-only > fetch operations.) > > > > > Looking at `debuginfod.h` I `debuginfod_set_progressfn` which looks > > > > ideal. But how do I access the default `debuginfod_client *` which > > > > seems to exist without me ever calling `debuginfod_begin` anywhere? > > > > Or do I need to create a new client here via `debuginfod_begin`? > > > > > > You do need to create a new client object. You can reuse it. > > > > Will the default code that uses debuginfod from within dwfl then pick up > > my > > new client object and use that? I feel like there's a fundamental > > confusion > > about this on my side about this. More on that at the end of this mail > > below. > > Ah yes, I didn't realize you were talking about the hidden debuginfod > client usage in libdwfl. Yes, you have not much control over that, > because it is .... hidden & automatic. There is a > DEBUGINFOD_PROGRESS env var with which it can activate some > notification to stderr, but that's about it. No API to get at the > internal transient objects. > > If you wish to take control of this part, you could probably still use > dwfl. You would do all the debuginfod client API calls yourself, then > "report" the dwarf file content to dwfl via dwarf_begin_elf(), > dwarf_begin(), dwarf_setalt() etc. OK thank you, that is helpful. Would you say adding dwfl API to get access to the internal debuginfod client would be a good path forward? I guess more projects would potentially like to benefit from the ready made integration, but add a bit of control on top of it? > > ``` > > $ man debuginfod_set_progressfn > > No manual entry for debuginfod_set_progressfn > > ``` > > Well go complain to your distro for this packaging bug. :-) > It's an alias of [man debuginfod_find_debuginfo]. Found it now - it's packaged together with `debuginfod`, even though it should be part of `elfutils`. > > My `debuginfod.h` also does not show any (useful) inline API > > documentation for most of that file. Could this please be improved? > > The doxygen for dwfl is great and can be read directly together with > > the code, > > As they say, patches welcome. :-) The header contains some curt > comments documenting each function. Would you be OK with me simply copying over the contents from the man page over to doxygen? Or is there a better process in place to prevent such kind of documentation duplication? I would have expected that the man pages for API documentation are generated from e.g. doxygen which does not seem to be the case here? Thanks -- Milian Wolff mail@milianw.de http://milianw.de --nextPart3109949.FXb7mknhcm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEezawi1aUvUGg3A1+8zYW/HGdOX8FAmJQkfoACgkQ8zYW/HGd OX9bvA//UYsdvb1HKYfB1UfU/u+XHmZcVy8kWoHyvt7mBUtug+rGgvHrp2RVqn3+ jMQXO5mJGmFvOOfmrvexbDfrPjYorZWy1Y/mKYgYYNZ18eaNrKko8HvYusRh6aDk BYZi0dF4/yZatpWRk2El9uBIl0hSbNAAO/xKRLgOa/pOio7LhTt5PClN7V+nYQ8S 3AHNDMD0n8dAoOMwt5DvSfuzMSq2QJsSA3jfEcptMjPX+WcGT0u4pOuYErIGB2W+ 8yy2RUyAXksU4XRxcN1Zt5apTfo2glF+cNpNhWl9kUDNb4QsOwdKY7uyg/y6RZED OaOX4TF3xVfUFwqMDPoxFDX9Du+Z1MW/kNrqf8y0MnEdEM76k3QtokmhHOgZjcg3 78GT4LXjOZ3JI0N5mwMbARY3G66CI/jAduTsSM/LUitg9/1BzeTh9d7hAnN6ndxO 8t5BZNry9zI0gmsHPP3fm7tU1nMc4+vgDFzdDHVn1OOMBm9RvX4Kf4GgyroGEpnf ez+Yp0ZWiHb4vHjQliG8I2oOGoCpv0mev+7/f8SzI+sGqXUUTPOTAJ0uFoD7P3T9 eMgmZfHkxLBL8FXtIqiYvDmcdZfYtf7+1jvefap/B6WSeTqSxRQhUgi2S9pXzOr7 bKPiOlM4WxF65DsUcdXoZxu0qV1KWKKzGmashJzWDRoK/Gd8Wu8= =QUnF -----END PGP SIGNATURE----- --nextPart3109949.FXb7mknhcm--