From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5393 invoked by alias); 1 Sep 2009 22:10:46 -0000 Received: (qmail 5384 invoked by uid 22791); 1 Sep 2009 22:10:45 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS 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, 01 Sep 2009 22:10:39 +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 n81MAaB8011296 for ; Tue, 1 Sep 2009 18:10:37 -0400 Received: from [IPv6:::1] (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 n81MAXdd008211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Sep 2009 18:10:36 -0400 Message-ID: <4A9D9BD9.7010005@redhat.com> Date: Tue, 01 Sep 2009 22:10:00 -0000 From: Keith Seitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Lightning/1.0pre Thunderbird/3.0b3 MIME-Version: 1.0 To: tromey@redhat.com CC: gdb-patches@sourceware.org Subject: Re: [RFA] dwarf2_physname References: <4A9C358E.2050904@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-09/txt/msg00033.txt.bz2 On 09/01/2009 02:26 PM, Tom Tromey wrote: > If this is a hardship for some reason we can discuss it. I don't have a problem *not* committing it, especially with all the 7.0 talk about. But it will be difficult for me to keep posting patches which refine earlier (uncommitted patches). Well, actually, it's not as much a problem for me as it is for maintainers. Stuff will be really hard to read/diff/try. [I think (TM).] But it's your (collective) call. Tell me what you'd like me to do, and I'll do it. > Keith> +/* A vector used during linkage name generation. */ > Keith> +typedef struct die_info *die_info_p; > Keith> +DEF_VEC_P (die_info_p); > Keith> +static VEC(die_info_p) *die_list; > > I wonder if a global is really necessary. > I didn't check. The global is there to avoid having to reallocate the thing every time dwarf2_physname is called. In a large C++ application, that could be MANY MANY MANY times. > So, something must be missing here -- either an explicit initialization > of the vec, or this should use VEC_safe_push. Yes, there *is* an explicit initialization in _initialize_dwarf2_read, but I did not include it in this revision of the patch, since it would not actually be used *until* I "flipped" the switch. In other words, you would have seen the initialization when the final patch was submitted. I apologize, I know this is going to be very confusing. Think of this first patch like a "big picture" design overview. Subsequent patches will build on/refine this until everything is ready to go in and be "turned on." The problem is that the necessary changes are /so/ pervasive that in order to avoid test suite failures, I would have to submit a several thousand line patch which touches dozens of files, and I was hoping to avoid doing that kind of "patch dumping" ('cause I don't like it when that is done). Again, let me know how you would like me to proceed, and I will happily try to accommodate you. The burden of review is on you (maintainers). I want to do what I can to make it as easy as possible for you. Keith