From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id sUzJHpLTN2CjOAAAWB0awg (envelope-from ) for ; Thu, 25 Feb 2021 11:42:58 -0500 Received: by simark.ca (Postfix, from userid 112) id 6A4601EF78; Thu, 25 Feb 2021 11:42:58 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 0DB301E789 for ; Thu, 25 Feb 2021 11:42:58 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 74CB5383541B; Thu, 25 Feb 2021 16:42:57 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 74CB5383541B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1614271377; bh=JJ1j1LkFoyqucgpbpG9Qsx5XAayn+xp03++IKopjffw=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=sHej78UL6GwCAtWsLdwZI2P8H88JMNjxg7YrZYxhQu9TPZC0HpOOvia5H2nKGCZJ4 3jh666Uv7+xb8p9FpfZ7CEnHM56M8etNEA/WAZfXsBIPJYZ57FRl/cjzzxfnuFcbf4 L2lmdNANrcdJ7AqjMpot5nja9GpkDYcH6KSBHy7M= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id 8563D3857032 for ; Thu, 25 Feb 2021 16:42:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8563D3857032 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-114-QYoVNBrxPc-LsV5JFfFQmg-1; Thu, 25 Feb 2021 11:42:50 -0500 X-MC-Unique: QYoVNBrxPc-LsV5JFfFQmg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 27C6110082F5; Thu, 25 Feb 2021 16:42:48 +0000 (UTC) Received: from redhat.com (ovpn-112-160.phx2.redhat.com [10.3.112.160]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C6B201980D; Thu, 25 Feb 2021 16:42:47 +0000 (UTC) Received: from fche by redhat.com with local (Exim 4.94) (envelope-from ) id 1lFJiv-0003xb-Vl; Thu, 25 Feb 2021 11:42:46 -0500 Date: Thu, 25 Feb 2021 11:42:45 -0500 To: Tom Tromey Subject: Re: build-ids, .debug_sup and other IDs Message-ID: <20210225164245.GC11313@redhat.com> References: <20210221231810.1062175-1-tom@tromey.com> <20210224150752.GA23884@tarox.wildebeest.org> <87a6rt1b12.fsf@tromey.com> MIME-Version: 1.0 In-Reply-To: <87a6rt1b12.fsf@tromey.com> User-Agent: Mutt/1.12.0 (2019-05-25) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: "Frank Ch. Eigler via Gdb-patches" Reply-To: "Frank Ch. Eigler" Cc: Mark Wielaard , dwz@sourceware.org, elfutils-devel@sourceware.org, gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" Hi - > FWIW I looked a little at unifying these. For example, > bfdopncls.c:bfd_get_alt_debug_link_info could look at both the build-id > and .debug_sup. > > But, this seemed a bit weird. What if both appear and they are > different? Then a single API isn't so great -- you want to check the ID > corresponding to whatever was in the original file. If both appear and are different, can we characterize the elf file as malformed? Does our current tooling produce such files? If it's an abnormality (requires special elf manipulation or whatever), we could avoid bending backward for this case, and tune the tools to the Normal. > [...] > I suppose a distro can ensure that the IDs are always equal. Via debugedit for example? > Maybe debuginfod could also just require this. Or debuginfod could export the content under -both- IDs, if there were two valid candidates, and just go with the flow. Let the clients choose which ID they prefer to look up by. - FChE