From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id jXlvH/fuxmCiOQAAWB0awg (envelope-from ) for ; Mon, 14 Jun 2021 01:53:59 -0400 Received: by simark.ca (Postfix, from userid 112) id 70B181F163; Mon, 14 Jun 2021 01:53:59 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_REPLYTO_END_DIGIT,MAILING_LIST_MULTI, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [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 961351E813 for ; Mon, 14 Jun 2021 01:53:58 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 785C838515E3 for ; Mon, 14 Jun 2021 05:53:57 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 785C838515E3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1623650037; bh=9tk7jNRttFWSP+NXz8VsoZTpVdAWCt243dtjCGpDWJQ=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=lpjSCyc2AEWxl6ZfNxsvekxUxgsT57lDsO+l4bo9Jz6y42E3BHAFiIORLf4JQAXDs GUZuWQiLGMdHcbgMSBNfFYvW/5zvS5gHvlxgiR+JIKV3dT7vC0iSVIevjdRSCn9SAr JCkw00BcQJEtThqneoFX4jSiqHMuwNyz8iMeAvCY= Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) by sourceware.org (Postfix) with ESMTPS id 5E1A6385482F; Mon, 14 Jun 2021 05:53:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5E1A6385482F Received: by mail-lj1-x236.google.com with SMTP id x14so18466777ljp.7; Sun, 13 Jun 2021 22:53:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9tk7jNRttFWSP+NXz8VsoZTpVdAWCt243dtjCGpDWJQ=; b=fFBxudpZ2ISpMxYxV7iEy9rMGoDkg8jqA02KiMJ+PQ6NPDR4qrBY9qgO5/5i8nMGNK spHXOV9UjF+mAtYKYafrEGwvEd3FIqe0JdJXYbiX2KoXIBMI7uLg8xOPeOJNY0iN2t2c DNVhmqpcLHeaMlKnr7CMYn1XsuKIadI7eGtK0ifUiNSvsomSycR1RyTVl5FQC9L4gxKq DRiA+8Udo6CF0RCgUq0R44p6DyxVdJLyd6AruUlQVj3pzQ0FQyT6NgXOkvUPodikqFwn r23VbEIcGchaSgPWSAg1UxeLLwABWhxbWjMVsAX4cLmCU/7Xh/jB7Ya9Z0cjYwA8Xot5 yCkw== X-Gm-Message-State: AOAM532KP3/AzaYsIVEdxpitDwj3qyJr/cDnrmnCPESdP5ggdhnqCpZh RvQdk8CfsiNcMnR/hQz5pOABd8VGJoF3oxdsPQ4= X-Google-Smtp-Source: ABdhPJwAgLbW9NYSENF0ERIhRtrZ68yusNJy1CMEGxFfgmTc5lhF5FTV6rvxVuIt/n6WBgfsJQFkBXG03ks4naMrg9I= X-Received: by 2002:a2e:bf12:: with SMTP id c18mr12262594ljr.407.1623650005137; Sun, 13 Jun 2021 22:53:25 -0700 (PDT) MIME-Version: 1.0 References: <20210221231810.1062175-1-tom@tromey.com> <20210224150752.GA23884@tarox.wildebeest.org> <8c0ada00-7516-a7a2-b08e-aaaf677dd4f6@redhat.com> <20210224172101.GB3014@wildebeest.org> In-Reply-To: Date: Sun, 13 Jun 2021 22:52:58 -0700 Message-ID: Subject: Re: build-ids, .debug_sup and other IDs (Was: [PATCH] Handle DWARF 5 separate debug sections) To: Nick Clifton Content-Type: text/plain; charset="UTF-8" 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: Matt Schulte via Gdb-patches Reply-To: Matt Schulte Cc: elfutils-devel@sourceware.org, Mark Wielaard , dwz@sourceware.org, Tom Tromey , gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Hi Mark, My apologies for bringing this up so late. I was just re-reading this thread while looking at how to find a .dwp for a given binary. > But I was personally assuming we would extend it to also to other things like > dwo IDs (which are again almost identical globally unique identifiers for > files) I'm concerned about using dwo IDs to index debuginfod. They are only 64-bits and there will be many more dwo IDs than build ids or supplemental file ids since there is 1 per compile unit. Assuming dwo IDs are randomly distributed, once we have ~600,000,000 dwo IDs we have a 1% chance of a collision. ~600,000,000 = sqrt(2 * 2^64 * 0.01) (I think I did that math right but forgive me if not). Maybe that's an ok number? (I tried to estimate the number of compile units in one distro's release, but do not have a good way of doing that quickly) What about using `/buildid/BUILDID/dwp` instead? This is not a perfect solution, since (currently) no one puts the build-id into the *.dwp file, but it does get around this collision problem. -Matt