From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19288 invoked by alias); 4 Sep 2007 07:21:45 -0000 Received: (qmail 19278 invoked by uid 22791); 4 Sep 2007 07:21:44 -0000 X-Spam-Check-By: sourceware.org Received: from rwcrmhc11.comcast.net (HELO rwcrmhc11.comcast.net) (216.148.227.151) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 04 Sep 2007 07:21:33 +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 <20070904072131m110012518e>; Tue, 4 Sep 2007 07:21:31 +0000 Received: from magilla.localdomain (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 49D3C357B; Tue, 4 Sep 2007 00:21:30 -0700 (PDT) Received: by magilla.localdomain (Postfix, from userid 5281) id 089B04D04CC; Tue, 4 Sep 2007 00:21:29 -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@redhat.com, gdb-patches@sourceware.org Subject: Re: [patch] build-id .debug files load (like .gnu_debuglink) In-Reply-To: Eli Zaretskii's message of Tuesday, 4 September 2007 06:23:34 +0300 X-Zippy-Says: It don't mean a THING if you ain't got that SWING!! Message-Id: <20070904072130.089B04D04CC@magilla.localdomain> Date: Tue, 04 Sep 2007 07: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/msg00042.txt.bz2 > We don't introduce such a new term, the above was a typo. The manual > does not use this term anywhere, it uses "build ID". Great. > > It is also not good to use the term "signature" loosely with relation to > > build ID bits. > > What alternative term would you suggest? I have no shares in this > particular word, if a good alternative exists. Well, there is "ID". Also "bit string", or "set of bits", or "sequence of bytes" come to mind. Whatever flows in the particular context to say what is so, which is that it is a small chunk of data taken solely as an identifier with no instrinsic meaning to its bits. The text I wrote in the ld manual (ld/ld.texinfo @node Options) uses "unique bits" and "bit string". Also, I don't think it is proper to refer to this as GNU/Linux operating system magic and refer to the Fedora wiki. The build ID note is a GNU convention for ELF binaries and the tool involved in creating it is GNU ld. It is the linker, and how the linker is used, that determines whether creating a binary normally gives it one. The GDB manual should refer directly to the GNU ld manual about how it's created. If you mean the manual to document precise format details, then it should not say that a build ID section is "named @code{.note.gnu.build-id}". That is the name of the input section that ld synthesizes under --build-id, and will often be the name of the final section seen in an executable or DSO. But the name is in no way magical and any tool would be broken if it worked only on a section by that name. It should be mentioned only as a common case. It is only the normative ELF data that controls what constitutes a proper build ID in an ELF file. That is, SHT_NOTE sections, or PT_NOTE segments in sectionless files, with proper ELF note formats of name "GNU" and type NT_GNU_BUILD_ID. The wording now says "executable" a lot, while in reality it can be any kind of ELF file that gdb would consider. That is, executables or DSOs (ET_EXEC/ET_DYN), or ET_REL files that are contemplated in their own right, as is done for Linux kernel modules. For all of these, gdb can find separate debug info, and should use build IDs to do so. Thanks, Roland