public inbox for dwz@sourceware.org
 help / color / mirror / Atom feed
From: Matt Schulte <schultetwin1@gmail.com>
To: Nick Clifton <nickc@redhat.com>
Cc: Mark Wielaard <mark@klomp.org>,
	dwz@sourceware.org, Tom Tromey <tom@tromey.com>,
	 elfutils-devel@sourceware.org, gdb-patches@sourceware.org
Subject: Re: build-ids, .debug_sup and other IDs (Was: [PATCH] Handle DWARF 5 separate debug sections)
Date: Sun, 13 Jun 2021 22:52:58 -0700	[thread overview]
Message-ID: <CAJqzY_7WSdDCrx=b7rmz0h-Lhw2u4hr6nwYBLwMwrudT3pizMg@mail.gmail.com> (raw)
In-Reply-To: <c6c0be0b-5e0c-b893-a16f-c500fbdb3893@redhat.com>

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

  reply	other threads:[~2021-06-14  5:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210221231810.1062175-1-tom@tromey.com>
2021-02-24 15:07 ` Mark Wielaard
2021-02-24 17:00   ` Nick Clifton
2021-02-24 17:21     ` Mark Wielaard
2021-02-25 17:52       ` Nick Clifton
2021-06-14  5:52         ` Matt Schulte [this message]
2021-06-14 12:49           ` Frank Ch. Eigler
2021-06-14 15:18             ` Matt Schulte
2021-02-24 20:11   ` build-ids, .debug_sup and other IDs Tom Tromey
2021-02-25 16:42     ` Frank Ch. Eigler
2021-02-25 16:48       ` Jakub Jelinek
2021-02-25 17:04         ` Frank Ch. Eigler
2021-03-02 22:05           ` Tom Tromey
2021-03-02 22:04       ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJqzY_7WSdDCrx=b7rmz0h-Lhw2u4hr6nwYBLwMwrudT3pizMg@mail.gmail.com' \
    --to=schultetwin1@gmail.com \
    --cc=dwz@sourceware.org \
    --cc=elfutils-devel@sourceware.org \
    --cc=gdb-patches@sourceware.org \
    --cc=mark@klomp.org \
    --cc=nickc@redhat.com \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).