From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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: From: Matt Schulte 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 Cc: Mark Wielaard , dwz@sourceware.org, Tom Tromey , elfutils-devel@sourceware.org, gdb-patches@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: dwz@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Dwz mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 05:53:27 -0000 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