From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32284 invoked by alias); 26 Jun 2009 01:33:41 -0000 Received: (qmail 32276 invoked by uid 22791); 26 Jun 2009 01:33:40 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 26 Jun 2009 01:33:34 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 9B47510557; Fri, 26 Jun 2009 01:33:31 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id 74FF7104AF; Fri, 26 Jun 2009 01:33:31 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1MK0Jm-0005Mv-1O; Thu, 25 Jun 2009 21:33:30 -0400 Date: Fri, 26 Jun 2009 01:33:00 -0000 From: Daniel Jacobowitz To: Doug Evans Cc: tromey@redhat.com, gdb-patches@sourceware.org, ccoutant@google.com Subject: Re: [RFA] comdat types Message-ID: <20090626013330.GA20206@caradoc.them.org> Mail-Followup-To: Doug Evans , tromey@redhat.com, gdb-patches@sourceware.org, ccoutant@google.com References: <20090620000402.C37E5843F5@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2009-06/txt/msg00700.txt.bz2 On Thu, Jun 25, 2009 at 01:28:02PM -0700, Doug Evans wrote: > > Doug> +  types_htab = htab_create_alloc_ex (41, > > Doug> +                              hash_type_signature, > > Doug> +                              eq_type_signature, > > Doug> +                              NULL, > > Doug> +                              &objfile->objfile_obstack, > > Doug> +                              hashtab_obstack_allocate, > > Doug> +                              dummy_obstack_deallocate); > > > > This is just a side note -- I've seen a few hash tables allocated on > > obstacks.  Doesn't resizing the table waste memory? > > IIRC I use the noresize traversal routine. > It's not ideal, no. FWIW, 3 of the other 4 hash tables are on the compilation unit obstack, which is temporary. The exception is type_hash which I found to be performance-sensitive (both time and space) and have a pretty good initial size estimate. Obstacks are a big win for that sort of thing. This one probably fills the same niche, but doesn't have an initial estimate. So I'm not sure what I think about keeping it on the obstack. If the contents can go on the obstack instead, that's probably enough. > > Doug> +  if (this_cu->from_debug_types) > > Doug> +    { > > Doug> +      /* ??? How come this is for .debug_types only?  */ > > Doug> +      this_cu->offset = cu.header.offset; > > Doug> +      this_cu->length = cu.header.length + cu.header.initial_length_size; > > > > Daniel has asked before for "no new FIXMEs".  You can't escape this by > > spelling it "???" :-) > > Well, that one was an oversight (these patches drag on and my eyes > tend to glaze over ...). > While as a general rule I don't disagree, it's kinda odd to see others > add new functionality with open issues. Yes, we're (me included) not totally consistent on this - but it's a sure way to get reviewers to chew on you, as you know :-) As a general extension to the general rule, "FIXME: Foo doesn't work" makes me happier than "FIXME: What about foo?". I particularly don't like FIXMEs with questions in them; we should know what works and what doesn't. -- Daniel Jacobowitz CodeSourcery