From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 546AC3858D28 for ; Fri, 8 Apr 2022 19:44:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 546AC3858D28 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-524-GJD-T0rlN-SzOuBxksuSkg-1; Fri, 08 Apr 2022 15:44:34 -0400 X-MC-Unique: GJD-T0rlN-SzOuBxksuSkg-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id AE850811E80; Fri, 8 Apr 2022 19:44:33 +0000 (UTC) Received: from redhat.com (unknown [10.2.16.64]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9E6A4403178; Fri, 8 Apr 2022 19:44:33 +0000 (UTC) Received: from fche by redhat.com with local (Exim 4.94.2) (envelope-from ) id 1ncuX2-00015i-Lp; Fri, 08 Apr 2022 15:44:32 -0400 Date: Fri, 8 Apr 2022 15:44:32 -0400 From: "Frank Ch. Eigler" To: Milian Wolff Cc: elfutils-devel@sourceware.org Subject: Re: Questions regarding debuginfod.h API Message-ID: <20220408194432.GB23295@redhat.com> References: <5817622.lOV4Wx5bFT@agathemoarbauer> <20220408134432.GA23295@redhat.com> <12359040.Dq0kRfdbeh@milian-workstation> MIME-Version: 1.0 In-Reply-To: <12359040.Dq0kRfdbeh@milian-workstation> User-Agent: Mutt/1.12.0 (2019-05-25) X-Scanned-By: MIMEDefang 2.85 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham 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:44:37 -0000 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. > ``` > $ 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]. > 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. > I never used `man` for that purpose in the past? There is a whole section of POSIX man pages for API docs: 3. - FChE