From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by sourceware.org (Postfix) with ESMTPS id 1B3FE3860C3E; Mon, 14 Jun 2021 15:19:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1B3FE3860C3E Received: by mail-lf1-x12e.google.com with SMTP id r198so21703141lff.11; Mon, 14 Jun 2021 08:19:08 -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=6X9R9EiQ6+mJs5xbG9Emh94QJW0H09vWLzJS5QoICX4=; b=JYguX1jOdtN7huH2EWKv2aof5m8rW4yj9pjc0Q8wQVcmN35aPhPktryJ1qKT6/IJb0 CdkHt6QEhktNF3SyzJAcJM2X7i96b891SqpTomzLQYQnVodTK6PFjXw1SUjCd/tcp8K7 Pl6lpfQFi3r0Fy4t92PJ0WF46utGyIB4dfVOX2IlplN6wJc0RvvaiGZh7wPrLj5fuF+Z Ii7Q5xKeMHgF2DQe5GTqdOk1pz10ziiwOhkg1iefrQkbrpogFp9zi+ePbMPltHZd408n EHACBaX+TIGPPVFl6+i1mhpPPwZYptE6WFDymysnW/L00GwV4LP2+a9+okYhk40OF/qg eDhQ== X-Gm-Message-State: AOAM532WGIdhk8tg06P9oT/zQaS8V8fBCRdec7ahFu0y4J/OtULjhcH1 WoogbdNl44jeJfYww7W5mynenwA9TF+VMuK/0Mk= X-Google-Smtp-Source: ABdhPJzHu6vfu6BkmD8jEp5/QUQ8LPq03AgTlFkySiuf4PHxTrKTjJbL6OaBGFSurjcxYVe5keBKaRiq4F49FAeeUKQ= X-Received: by 2002:a19:3846:: with SMTP id d6mr13282101lfj.187.1623683946629; Mon, 14 Jun 2021 08:19:06 -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> <20210614124920.GD3758@redhat.com> In-Reply-To: <20210614124920.GD3758@redhat.com> From: Matt Schulte Date: Mon, 14 Jun 2021 08:18:39 -0700 Message-ID: Subject: Re: build-ids, .debug_sup and other IDs (Was: [PATCH] Handle DWARF 5 separate debug sections) To: "Frank Ch. Eigler" Cc: Nick Clifton , elfutils-devel@sourceware.org, Mark Wielaard , dwz@sourceware.org, Tom Tromey , gdb-patches@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.5 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 15:19:09 -0000 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