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 86DCA3858D28 for ; Fri, 8 Apr 2022 19:09:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 86DCA3858D28 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 4F359240115; Fri, 8 Apr 2022 21:09:25 +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:09:24 +0200 Message-ID: <12359040.Dq0kRfdbeh@milian-workstation> In-Reply-To: <20220408134432.GA23295@redhat.com> References: <5817622.lOV4Wx5bFT@agathemoarbauer> <20220408134432.GA23295@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart103140060.6efXnXDxqn"; 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:09:29 -0000 --nextPart103140060.6efXnXDxqn 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:09:24 +0200 Message-ID: <12359040.Dq0kRfdbeh@milian-workstation> In-Reply-To: <20220408134432.GA23295@redhat.com> On Freitag, 8. April 2022 15:44:32 CEST Frank Ch. Eigler wrote: > Hi - > > Now to my question: In applications using elfutils, we will now > > automatically download debug information when DEBUGINFOD_URLS is > > defined. But doing that can take a very long time. > > (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. This simply takes time (in total), whereas the two environment variables above would be per-library, no? And usually one does not know a priori which libraries one needs - the size is not really a good criterium to decide whether to download a libraries debug information or not... I'm not really complaining here - just thinking out loud. I believe for novice users the status quo is acceptable - they'll just need to wait for the download to finish (potentially taking minutes). More advanced users may want to manually skip some (larger) libs that they know they won't use for whatever they are looking at... > > I would like to give the user feedback about this situation and > > ideally provide a means to cancel the download. > > OK. > > > 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. > > Then, how would I cancel an ongoing download job? GDB seems to do > > that when I press `CTRL+C`, but I do not see any API I could use for > > that purpose? > > See [man debuginfod_set_progressfn]. The return code from that > progressfn callback is the ticket. ``` $ man debuginfod_set_progressfn No manual entry for debuginfod_set_progressfn ``` 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, I never used `man` for that purpose in the past? > > Finally, what is the recommended way to check whether debuginfod is > > available? Should one rely on the build system to discover the > > `debuginfod.h` header file, or is some other compile time check > > suggested to detect it? [...] > > To decide whether or not to compile in support, you'd need a > compile-time check such as for the debuginfod.h header. (Alternately, > you could opt not to compile in support at all, and instead call out > to the debuginfod-find(1) program.) To decide at run time whether or > not to use it, you could just use the *_find APIs and get back an > error code if things are not set up. Or you can check the > DEBUGINFOD_URLS for being set/unset before you call in. I don't see where I would use debuginfod-find or any of the `debuginfod_find_*` API directly. I'm using dwfl which uses debuginfod internally. I guess that happens via the `dwfl_*find_*` standard callbacks provided in `libdwfl.h`. That works perfectly fine. I simply want a bit more control over the debuginfod usage that happens internally in dwfl. Is maybe a `debuginfod_client *dwfl_debuginfod(void)` function missing that gives access to the client used by dwfl internally? Thanks -- Milian Wolff mail@milianw.de http://milianw.de --nextPart103140060.6efXnXDxqn 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/HGdOX8FAmJQiGQACgkQ8zYW/HGd OX8KrBAAqEqGHy9ASpstXz9Cv/dhKat2IjLlEtaGJ7LfZzOH5TYNL3DBIc5coZKd VKHDh3c0m30rKd1DrnjbgUjKm5j0DFfBEjF4fQEPY/7P4KEwc8tN3wYNolmY9F6U 47Y7bvJ7sGXvt1NonLa1G4dn//iD6YX0sCP1lDAvg8I39bYLKwna7KT+OnJ3yV3m ccV+i/bgd+PbfoGWAIYHC9VmY5DtyBGQW3rcyzEEF4hffnSk/KzRrQsphSDRKRqB ujTXRAnJnPdU5vNpTnAaaAGgm1E3S3jbVWES1X5IAEKpvkhEiUzBK3Jj7GTdwmxt QZeeEaEUNiCUZaQXJWAaeKD4vKIAwAG7a52MY8ZUOvI/Ea5JMzmSoy1U5UfJfEJL oLg0B9UASzIw7TeEYnlB1ffwAaR6mzvWZaYwBRnpv3/gh3bURl+91imNtvS/TiLO q/rjB899KLxVA9muIjmvHdyv4rAGJSPMKu9gnj4RictHO+2HHMnxiZWFEqrREi9z Kq5AdvcmEWfED19NucN6jwRL6LMC6pvtwoqsJCVR8Zw7w4GdAlxJvTPmVI2vGu1c HdQjBK2kwI3Y9tqeHiIgL7UN+ApW/DyKA5gpF9ebHbKUXHJguweQQuld6iQSQapB WL16ElLsj8AVpA21H008lPfEih4zdnV0XIev9T/N6HivYXcmpOA= =bUqD -----END PGP SIGNATURE----- --nextPart103140060.6efXnXDxqn--