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 502083858D28 for ; Sat, 9 Apr 2022 13:44:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 502083858D28 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 5EA332402BB for ; Sat, 9 Apr 2022 15:44:34 +0200 (CEST) From: Milian Wolff To: elfutils-devel@sourceware.org Subject: Expanding control over debuginfod usage from dwfl [was: Re: Questions regarding debuginfod.h API] Date: Sat, 09 Apr 2022 15:44:34 +0200 Message-ID: <2782414.8Vx5aUIOYe@milian-workstation> In-Reply-To: <15044726.Ck1BFTr2H8@milian-workstation> References: <5817622.lOV4Wx5bFT@agathemoarbauer> <20220408194432.GB23295@redhat.com> <15044726.Ck1BFTr2H8@milian-workstation> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart24286165.PiYnE7HUhT"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Spam-Status: No, score=1.1 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-Level: * 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: Sat, 09 Apr 2022 13:44:36 -0000 --nextPart24286165.PiYnE7HUhT Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii"; protected-headers="v1" From: Milian Wolff To: elfutils-devel@sourceware.org Date: Sat, 09 Apr 2022 15:44:34 +0200 Message-ID: <2782414.8Vx5aUIOYe@milian-workstation> In-Reply-To: <15044726.Ck1BFTr2H8@milian-workstation> On Freitag, 8. April 2022 21:50:18 CEST Milian Wolff wrote: > On Freitag, 8. April 2022 21:44:32 CEST Frank Ch. Eigler wrote: > > > 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? I looked into this a bit more, and would like to expand the dwfl API to give more control over how it uses debuginfod internally. Without any API changes, I currently can not disable debuginfod usage in dwfl. Well, the only option would be to unset the environment variable before any call into dwfl. But if I would roll my own debuginfod client code, it would still depend on the environment variable - thus the code would become quite ugly with repeated setenv/unsetenv pairs. Additionally, the debuginfod client code in dwfl is good and well tested. Rolling my own just to get progress reporting and cancellation sounds like a waste of time to me. Thus my proposal, and RFC: ``` /* Let us mirror the debuginfod progressfn for dwfl and forward it to the internal debuginfod client, if available. This way, dwfl's usage of debuginfod can stay optional and we would not need to link to debuginfod directly from code using dwfl. */ typedef int (*dwfl_debuginfod_progressfn_t)(Dwfl *dwfl, long a, long b); extern void dwfl_set_debuginfod_progressfn(Dwfl *dwfl, dwfl_debuginfod_progressfn_t fn); ``` This would already greatly help me. Better yet, we would eventually also add some more information to the progress callback, such as the name of the library that has triggered the download. But that could be done in a follow up patch, in a fashion similar to `debuginfod_get_url` I believe. Alternatively: ``` /* We could just give full access to the internal client but doing so may clash with future usages of e.g. debuginfod_{set,get}_user_data in dwfl and users of dwfl. Otherwise, this is obviously easiest and gives most flexibility. We just need to forward get_client from debuginfod-client.c */ extern debuginfod_client *dwfl_debuginfod_client (Dwfl *); ``` What do you all think? Cheers -- Milian Wolff mail@milianw.de http://milianw.de --nextPart24286165.PiYnE7HUhT 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/HGdOX8FAmJRjcIACgkQ8zYW/HGd OX/V+hAA10S7mutj3hVys4MDUxcZsltVJ7qxa7e7Oj/iSsAOUpPCHrVLdi31dRdx ToQu+reaab3VuYsHfNf/0Vn8M/VDk8PWx/iF7JD3DdN/I6vWI9RofWYjYyoGzOxV 8lfWHxQyMcBuwGq1G3Ux34z6qevz11wI/Sd6D+Xo1d8wF5ptu1pewHcrJnbnvtG8 8QNBgkch9uiOReedjE/RWednWAKXErgDlXkkdnGdqUsGUul04Th0ibxxAPZYcWLb exasu6vfue7ZfPbPJ4W+5zqFOCb5IENrTvtuebErynmxzTioK2Oy5biV5CFzXiV/ 66bDqsj2hTuXNNSqMYx5NltksQAjxtUvIgreHRVNwdWh0kpYPlLJJLsuVdK1FUHE QLC6/ipCbW5tKMzK2MfEVVefgRQX2XSD9iM7jWxh5pgLVhQz78Rym8Uy3VLhxrrD SkyBTrv7/R9BVssz0ymr7W2neIhF8ucFcuuormav0buWtUaGYn9Se6GEsZeYr896 1EQI2rjAIkLuhIboiIgMe94zxNILTdbMvk4mTjrU8AUyoJl8jeyjWrMWe9ZM3Qpl NhnUE217vWsMCfuwlQ2kJBzUlt54IYIlcvLqHWyg5UOQc12fAWG7WyiK/HWNIzhj O39GvhMj9AI0Ui893LfKTJj19rGA3DuSIlCogMyCe8ANSkCUyns= =Zsqp -----END PGP SIGNATURE----- --nextPart24286165.PiYnE7HUhT--