public inbox for dwz@sourceware.org
 help / color / mirror / Atom feed
From: Matt Schulte <schultetwin1@gmail.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: Nick Clifton <nickc@redhat.com>,
	elfutils-devel@sourceware.org,  Mark Wielaard <mark@klomp.org>,
	dwz@sourceware.org, Tom Tromey <tom@tromey.com>,
	gdb-patches@sourceware.org
Subject: Re: build-ids, .debug_sup and other IDs (Was: [PATCH] Handle DWARF 5 separate debug sections)
Date: Mon, 14 Jun 2021 08:18:39 -0700	[thread overview]
Message-ID: <CAJqzY_4AbAqSG0NeHqFx7uqCvAsktitWme-zPHSEJwht0FUdVg@mail.gmail.com> (raw)
In-Reply-To: <20210614124920.GD3758@redhat.com>

Thanks for the thoughts!

> AIUI, -gsplit-dwarf is more suitable for development/scratch builds
> than for distro binaries.  If distros agree, then I would not expect
> .dwo files to show up in distro-wide debuginfod services, but rather
> within developers' own build trees.

That's a good point. My concerns are only valid if distros decide to
start building packages using -gsplit-dwarf and dwp to package up
the .dwo files into one .dwp file.

I also agree that split dwarfs (split dwarves?) are more suitable for
local builds than for distro builds. The one advantage I can think
of that split dwarfs offer distro binaries is a faster build for
larger packages (since dwp does not do all the relocations the
linker would normally do). But I don't know enough about building
packages to say what will happen in the future.

> The hypothetical problem is collision between dwo/dwp files, not
> between dwo/dwp and normal buildid dwarf files, right?

That's correct.

> In that case, are you talking about two levels of indexing (buildid
> of final linked binary + dwo_id)?

I was suggesting one level of indexing. The buildid of the final linked
binary would be used to reference the dwp file directly. This solution
would not work for individual dwo files. For individual dwo files we
could still use the dwo_id as they should only be for local builds.

-Matt

  reply	other threads:[~2021-06-14 15:19 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
2021-06-14 12:49           ` Frank Ch. Eigler
2021-06-14 15:18             ` Matt Schulte [this message]
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_4AbAqSG0NeHqFx7uqCvAsktitWme-zPHSEJwht0FUdVg@mail.gmail.com \
    --to=schultetwin1@gmail.com \
    --cc=dwz@sourceware.org \
    --cc=elfutils-devel@sourceware.org \
    --cc=fche@redhat.com \
    --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).