From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7060 invoked by alias); 14 Jun 2010 20:06:29 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 7041 invoked by uid 22791); 14 Jun 2010 20:06:27 -0000 X-SWARE-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org From: Tom Tromey To: Roland McGrath Cc: Project Archer , Jakub Jelinek Subject: Re: Fedora 14 debug proposal References: <20100613104010.6D1174077C@magilla.sf.frob.com> Reply-To: Tom Tromey Date: Mon, 14 Jun 2010 20:06:00 -0000 In-Reply-To: <20100613104010.6D1174077C@magilla.sf.frob.com> (Roland McGrath's message of "Sun, 13 Jun 2010 03:40:10 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2010-q2/txt/msg00051.txt.bz2 Tom> 1. Generate index files for the separate .debug files. This Tom> involves running gdb to dump the index, something like: Roland> Is this a magical gdb-internal format, or something that will Roland> really be specified as a known file format? Since the plan as Roland> stated is to distribute this format in distro packages that will Roland> be around forever, the format details become interesting from a Roland> long-term compatibility point of view, not just as a gdb feature Roland> of today. Magical gdb format. I've appended the comment that documents it. Tom> 2. Change GCC so that it no longer emits .debug_aranges, Tom> .debug_pubnames, and .debug_pubtypes. Roland> Please do not lump .debug_aranges in with .debug_pub*. They are Roland> qualitatively different cases. .debug_aranges is a direct low-level Roland> derivative of the CU DIEs. The others are made with language-specific Roland> high-level knowledge. Ok. Tom /* The mapped index file format is designed to be directly mmap()able on any architecture. In most cases, a datum is represented using a little-endian 32-bit integer value, called an offset_type. Big endian machines must byte-swap the values before using them. Exceptions to this rule are noted. The data is laid out such that alignment is always respected. A mapped index consists of several sections. 1. The file header. This is a sequence of values, of offset_type unless otherwise noted: [0] The version number. Currently 1. [1] The mtime of the objfile, as a 64-bit little-endian value. [2] The size of the objfile, as a 64-bit little-endian value. The size and mtime are used to confirm that the index matches the objfile. [3] The offset, from the start of the file, of the CU list. [4] The offset, from the start of the file, of the address section. [5] The offset, from the start of the file, of the symbol table. [6] The offset, from the start of the file, of the constant pool. 2. The CU list. This is a sequence of pairs of offset_type values. The first element in each pair is the offset of a CU in the .debug_info section. The second element in each pair is the length of that CU. References to a CU elsewhere in the map are done using a CU index, which is just the 0-based index into this table. 3. The address section. The address section consists of a sequence of address entries. Each address entry has three elements. [0] The low address. This is a 64-bit little-endian value. [1] The high address (plus one). This is also a 64-bit little-endian value. [2] The CU index. This is an offset_type value. 4. The symbol table. This is a hash table. The size of the hash table is always a power of 2. The initial hash and the step are currently defined by the `find_slot' function. Each slot in the hash table consists of a pair of offset_type values. The first value is the offset of the symbol's name in the constant pool. The second value is the offset of the CU vector in the constant pool. If both values are 0, then this slot in the hash table is empty. This is ok because while 0 is a valid constant pool index, it cannot be a valid index for both a string and a CU vector. A string in the constant pool is stored as a \0-terminated string, as you'd expect. A CU vector in the constant pool is a sequence of offset_type values. The first value is the number of CU indices in the vector. Each subsequent value is the index of a CU in the CU list. This element in the hash table is used to indicate which CUs define the symbol. 5. The constant pool. This is simply a bunch of bytes. It is organized so that alignment is correct: CU vectors are stored first, followed by strings. */