From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15943 invoked by alias); 4 Sep 2007 02:21:36 -0000 Received: (qmail 15927 invoked by uid 22791); 4 Sep 2007 02:21:34 -0000 X-Spam-Check-By: sourceware.org Received: from rwcrmhc11.comcast.net (HELO rwcrmhc11.comcast.net) (204.127.192.81) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 04 Sep 2007 02:21:28 +0000 Received: from gateway.sf.frob.com (c-67-160-211-197.hsd1.ca.comcast.net[67.160.211.197]) by comcast.net (rwcrmhc11) with ESMTP id <20070904022125m110015boje>; Tue, 4 Sep 2007 02:21:25 +0000 Received: from magilla.localdomain (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id EAE94357B; Mon, 3 Sep 2007 19:21:23 -0700 (PDT) Received: by magilla.localdomain (Postfix, from userid 5281) id 458E44D04CC; Mon, 3 Sep 2007 19:21:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Eli Zaretskii Cc: Jan Kratochvil , gdb-patches@sourceware.org Subject: Re: [patch] build-id .debug files load (like .gnu_debuglink) In-Reply-To: Eli Zaretskii's message of Saturday, 1 September 2007 15:15:07 +0300 X-Antipastobozoticataclysm: Bariumenemanilow Message-Id: <20070904022123.458E44D04CC@magilla.localdomain> Date: Tue, 04 Sep 2007 02:21:00 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-09/txt/msg00040.txt.bz2 > But the first command, the one to create the separate debug info file, > is still needed, right? Nothing about the recommended user procedure for making separate debug files has changed. Using --add-gnu-debuglink is not strictly required when using only new consumers that honor build ID notes, and dealing only with binaries that were linked with ld --build-id. But there is no reason not to do it and it is still required in the event of linking without --build-id or if concerned with all existing tools that understand .gnu_debuglink but not build ID notes. It is the case that strip and objcopy behavior wrt allocated notes sections has changed, and that the new behavior is required for build IDs to be preserved in separate debug files. However, I don't think there is any reason to burden the user with these details explicitly in the primary documentation on the subject. (Hence, there is no need to worry about how to identify versions of binutils here in the manual.) No version, derivative release, snapshot, or chronological state of development in binutils has included an ld supporting --build-id but an objcopy that treated it with the old rules. The objcopy and other tools involved in splitting a binary into a separate debug file should be no older than the ld used to create the original binary. If anything, that's all that needs to be said in the recipe. It's beyond unusual for the ld and objcopy et al one is usng not to have come from the very same build/package, so it's really not something to worry about. > This is fine, but there's no need to quote ``debug ID'' every time you > use it. I quoted it only when I used it as a name of a method of > embedding information about the debug file; in other cases I used it > without quotes. The canonical term is "build ID", and I do not think it is helpful to introduce "debug ID" in any documentation. In fact, the feature per se does not relate directly to debugging information, though that is indeed the largest motivation for its use. It is also not good to use the term "signature" loosely with relation to build ID bits. I would prefer to avoid that term entirely, except perhaps in a section devoted to discussing selection of ID bits and the issues of uniqueness and repeatability in detail. I am concerned about too easily creating misunderstandings that build ID bits relate to some sort of guarantee about the origin of binaries or security checks, which they do not. (As far as the fundamental feature itself goes, a build ID gives some bits that the creator of the binary decided to tell you were useful as an identifier for the binary. binutils and ld have nothing more to say about it than that.) Thanks, Roland