From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19619 invoked by alias); 6 Jul 2010 16:50:42 -0000 Received: (qmail 19606 invoked by uid 22791); 6 Jul 2010 16:50:41 -0000 X-SWARE-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_BJ,TW_JC,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 06 Jul 2010 16:50:36 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o66GoYJ0010959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 6 Jul 2010 12:50:34 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o66GoX8Z025244; Tue, 6 Jul 2010 12:50:34 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o66GoXj4014707; Tue, 6 Jul 2010 12:50:33 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id CD6DB3784BE; Tue, 6 Jul 2010 10:50:32 -0600 (MDT) From: Tom Tromey To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: [3/4] RFC: add DWARF index support References: <20100704181758.GA30603@host0.dyn.jankratochvil.net> Date: Tue, 06 Jul 2010 16:50:00 -0000 In-Reply-To: <20100704181758.GA30603@host0.dyn.jankratochvil.net> (Jan Kratochvil's message of "Sun, 4 Jul 2010 20:17:58 +0200") 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 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: 2010-07/txt/msg00095.txt.bz2 >>>>> "Jan" == Jan Kratochvil writes: Tom> +/* All offsets in the index are of this type. It must be Tom> + architecture-independent. */ Tom> +typedef uint32_t offset_type; Jan> It should be 64bit, Fedora already has to carry 64bit obstack patch Jan> for >2GB .debug files. I have seen only an artificial reproducer Jan> for >2GB .debug, no real world case, though. Jan> http://sourceware.org/ml/libc-alpha/2007-01/msg00090.html Yeah, thanks. I will fix this. My thinking is that we only need 64 bit for CU offsets. It seems very unlikely to me that an index file could be bigger than 4G (not 2G, since the offsets are all unsigned). Also I have been thinking a little about the 64 bit obstack patch. I think we can avoid it by going a different route: First, if we are mmap()ing debug sections, I doubt we need a 64 bit obstack. The bulk of the data will just be mapped. Second, if we have a section we cannot map (say it is compressed or something), we could just malloc memory for it instead of using the obstack. The last "read DWARF in the background" patch has the needed infrastructure to make this work ok, basically having a destructor function for sections in dwarf2read.c. What do you think? Tom> + 1. The file header. This is a sequence of values, of offset_type Tom> + unless otherwise noted: Jan> I would prefer there some simple magic (for file(1)). Good idea, I will do that. Tom> + [0] The version number. Currently 1. Tom> + [1] The mtime of the objfile, as a 64-bit little-endian value. Jan> Do you have some specific needs for storing timestamp into the file? Jan> When such index files will be packaged by distros it may create needless Jan> differences across various verifications. Isn't make(1)-like timestamp Jan> dependency enough? If the distro processes modify timestamps, then it seems like we also could not rely on them to remain ordered. The timestamp is only there to provide some assurance that the index really indexes the debug file. I thought the size alone was not enough -- but that some real checksum would be too slow. One idea would be to store the build-id and only verify it if the objfile has a .note.gnu.build-id section. Another idea is to make the user use objcopy to put the new data into the objfile. I am not very fond of this, though. In my experiments I think objcopy had bugs dealing with separate debug files. Tom