From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15002 invoked by alias); 6 Jul 2010 17:11:57 -0000 Received: (qmail 14987 invoked by uid 22791); 6 Jul 2010 17:11:55 -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,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 17:11:48 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o66HBj4K015636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 6 Jul 2010 13:11:46 -0400 Received: from host0.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o66HBhIL013111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jul 2010 13:11:45 -0400 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.4/8.14.4) with ESMTP id o66HBhN9024737; Tue, 6 Jul 2010 19:11:43 +0200 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.4/8.14.4/Submit) id o66HBg0w024735; Tue, 6 Jul 2010 19:11:42 +0200 Date: Tue, 06 Jul 2010 17:11:00 -0000 From: Jan Kratochvil To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [3/4] RFC: add DWARF index support Message-ID: <20100706171142.GA24412@host0.dyn.jankratochvil.net> References: <20100704181758.GA30603@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) X-IsSubscribed: yes 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/msg00096.txt.bz2 On Tue, 06 Jul 2010 18:50:32 +0200, Tom Tromey wrote: > 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: [...] > 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? Frankly, I do not want to reinvent the optimizations for tiny, small, medium, compact, large and huge memory models. :-) Any size should be 64bit and it is a bug if it is not. I was reluctant to make review notes on more places using `int' memory sizes in your patch. I find needlessly labor-expensive to evaluate each memory size if it really can always fit in 32bit or not. > 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. With various filesystems and network filesystems having interesting timestamp rules it would be best to avoid depending on it at all. > One idea would be to store the build-id and only verify it if the > objfile has a .note.gnu.build-id section. Good point, I find .gdb-index file should have exactly the same verification rules as the .debug file has. (That is crc32 if build-id is not available.) Thanks, Jan