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.129.124]) by sourceware.org (Postfix) with ESMTPS id 077573846431 for ; Wed, 26 Oct 2022 15:28:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 077573846431 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666798120; 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: in-reply-to:in-reply-to:references:references; bh=zrQ3eqf3Wphj/y4e9Bc+gCmOui3XLadEY+R8unL4UIs=; b=idssTrnHLpXXWsSFJ5L/tLBj+eqoTapYad4IEMDf7K15FAQgLPH/Q94raEY6xCcdzJ/RbS 0Ah+V9a8Ke3neAvL4v0tmOZwOKK1oZyS87np6mfKYTic51/Po5uCgq5JY8VGyMrQZEyNLf pc+ghkrcAKKv+XhPmE0zuG3IXEWRGwE= 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-493-Rr97SoDbPzamr3drFJ7MDw-1; Wed, 26 Oct 2022 11:28:39 -0400 X-MC-Unique: Rr97SoDbPzamr3drFJ7MDw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C0B26833A0F; Wed, 26 Oct 2022 15:28:38 +0000 (UTC) Received: from redhat.com (unknown [10.2.16.25]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B0AAB17595; Wed, 26 Oct 2022 15:28:38 +0000 (UTC) Received: from fche by redhat.com with local (Exim 4.94.2) (envelope-from ) id 1oniKb-0002ov-R2; Wed, 26 Oct 2022 11:28:37 -0400 Date: Wed, 26 Oct 2022 11:28:37 -0400 From: "Frank Ch. Eigler" To: Mark Wielaard Cc: Aaron Merey , elfutils-devel@sourceware.org Subject: Re: [PATCH] debuginfod: Support queries for ELF/DWARF sections Message-ID: <20221026152837.GE16441@redhat.com> References: <20221021000651.413015-1-amerey@redhat.com> <20221022000916.58609-1-amerey@redhat.com> <20221024183809.GB16441@redhat.com> <812188fca24baaa4a14e2cb15dcf2c50cef198c9.camel@klomp.org> MIME-Version: 1.0 In-Reply-To: <812188fca24baaa4a14e2cb15dcf2c50cef198c9.camel@klomp.org> User-Agent: Mutt/1.12.0 (2019-05-25) X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 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=-8.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi - > Is/should the section name be URL-encoded? Yes! > I would drop the maybe_debuginfo_section heuristics. There are some > sections like .strtab/.symtab that are probably in the debug file, but > might be in the executable. I would assume that a named section can > normally be found in the debugfile and only use the executable as > fallback. That heuristic would work fine for the case of .gdb_index, that motivated this whole piece of work. Sure. > Finally, if the section comes from a file in the cache or if we have to > download it in full anyway, then extracting the section into its own > file seems slightly wasteful. It would be great if we could just report > back "here is the full exe/debug file which does contain the requested > section name". [...] It'd be fine to pass back the extracted section content anyway, even if the full elf and/or dwarf file is already there. Consider federated debuginfod servers. Intermediate servers may be willing/able to do this extraction on behalf of clients who really only want the section in question. And if they cache the result, as in amerey's draft code, then this will also help accelerate other future clients. That's just the usage scenario (gdb acceleration). > int > debuginfod_find_section (debuginfod_client *client, > const unsigned char *build_id, > int build_id_len, > const char *section, char **path, > bool *file_is_elf) > > Maybe that is over-designed to avoid a little bit of disk waste? (Then the client code would have to learn elfutils API internals in order to extract the section it was actually interested in.) - FChE