From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57241 invoked by alias); 30 Oct 2019 13:40:48 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 57230 invoked by uid 89); 30 Oct 2019 13:40:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=instantly, love, our X-Spam-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (207.211.31.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 30 Oct 2019 13:40:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1572442845; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UTy6oYyLwIxqq8oW+G2q4sePEAqml3T+X5YtgQINeA0=; b=AHBBACOZG+p1hjH5oPJbvjAjoJ/zy2299M9GMlUEEoXxrE6Gmt00goLItPzYmMgC6KxulC HgD+xdM2QmQDEOLOmzFubCNPRuIsKegs2J8rVHBv1e0OOdBNjgQkRXBsWyCJQ80qLCuL5q 5ALgOzvRuULyfMzJpNjKZcAQMvyPsIE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-321-5mtoZ47bPkOeTOZnG__Eww-1; Wed, 30 Oct 2019 09:40:40 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id F2EC0800C61; Wed, 30 Oct 2019 13:40:39 +0000 (UTC) Received: from redhat.com (ovpn-116-53.phx2.redhat.com [10.3.116.53]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AB21F60872; Wed, 30 Oct 2019 13:40:36 +0000 (UTC) Received: from fche by redhat.com with local (Exim 4.92) (envelope-from ) id 1iPoDD-0003pe-32; Wed, 30 Oct 2019 09:40:35 -0400 Date: Wed, 30 Oct 2019 13:40:00 -0000 From: "Frank Ch. Eigler" To: Mark Wielaard Cc: elfutils-devel@sourceware.org, amerey@redhat.com Subject: Re: patch 0/2 debuginfod submission Message-ID: <20191030134035.GA10208@redhat.com> References: <20191028190438.GC14349@redhat.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.12.0 (2019-05-25) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-MC-Unique: 5mtoZ47bPkOeTOZnG__Eww-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-IsSubscribed: yes X-SW-Source: 2019-q4/txt/msg00084.txt.bz2 Hi, Mark - > I only browsed through the code quickly, but I like what I see. > For now just a comment on the libdwfl integration. Righto. > It is guarded by ENABLE_DEBUGINFOD, which is off by default. > I think the support should always be enabled in libdwfl whether or not > the debuginfod server is build or not, or that it should be guarded by > something like ENABLE_DEBUGINFOD_CLIENT_SUPPORT (which would default to > on by default). [...] OK, sure, IMO don't even bother with a guard. It's just a dlopen/dlsym, which is portable. Will update the first patch on the branch with that. > Also I think you should cache a negative result for > fp_debuginfod_find_debuginfo (say assign it (void *) -1) so you don't > keep trying to find the library/symbol each and every time. Will look into that later on. With the debuginfod server, a negative hit comes back instantly (no file searching, just an indexed database lookup), so this may not be a big deal. > Having parallel code on my mind I am worried now how this works when > called concurrently from two threads. There is a lot of code in libdwfl > that isn't concurrent-safe at the moment. But if possible lets not > introduce more. Not a big concern, but nice if you could give it a > thought. The new client-side code doesn't call into elfutils though, so does not amplify hypothetical problems there. In fact I'm not sure it's multithreaded at all, or just nonblocking I/O. The server is multithreaded, but that's relatively unavoidable, and turns out to work without any valgrind complaints (last time I tried). > Similarly, our error reporting is already pretty poor, so you aren't > making things worse. But have you thought about a way for the libdwfl > user to provide some way to indicate why something couldn't be > resolved/found? Again, not really a big concern since the current code > already has very limited/poor error reporting, but maybe you have > thoughts about it? We document returning standard errnos generally, and a few particular ones for network unreachability. > Have you thought about just calling debuginfod-find from the libdwfl > code? Or is execing from a library really just a no-no? It's not great as a practice. (We do that from debuginfod to popen rpm2cpio but reluctantly, and carefully with signals.) Another reason for calling directly is avoidance of a race condition, wherein two debuginfod-client processes run at the same time, and one cleans the cache right under the foot of the other. From the C API, you're guaranteed to get a usable fd, even if the underlying file was unlinked while you were looking. An fd is all elfutils needs (which I love). - FChE