From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id K9XLG4tzx2DyRgAAWB0awg (envelope-from ) for ; Mon, 14 Jun 2021 11:19:39 -0400 Received: by simark.ca (Postfix, from userid 112) id 631B61F163; Mon, 14 Jun 2021 11:19:39 -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 A35A71E813 for ; Mon, 14 Jun 2021 11:19:38 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 35F0E393BC0E for ; Mon, 14 Jun 2021 15:19:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 35F0E393BC0E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1623683978; bh=6X9R9EiQ6+mJs5xbG9Emh94QJW0H09vWLzJS5QoICX4=; 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=e2D5q+geGi+hbDQNpRjil8YapfU0ekdkwfBxJpKfN6ZW0NJaEg6B0c0tbDM9efYvn ZUZv/iEiXo3coKcaoWsfF9XgzWQhO6QRBZm0+TsNPU8PkzoRtx42zwKsWlypFDXwI7 9TOkYscxmBnmcPbE+RGOp+TMhcnKorgIBrwaPxA8= 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> 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" 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: dwz@sourceware.org, Nick Clifton , Mark Wielaard , Tom Tromey , elfutils-devel@sourceware.org, gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" 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