From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30338 invoked by alias); 14 Apr 2003 21:33:12 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 30330 invoked from network); 14 Apr 2003 21:33:11 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 14 Apr 2003 21:33:11 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h3ELX4X23096; Mon, 14 Apr 2003 14:33:04 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Elena Zannoni Cc: gdb-patches@sources.redhat.com, Daniel Jacobowitz , Jim Blandy Subject: Re: [rfa] annotate blocks with C++ namespace information References: <20030311171133.GA3362@nevyn.them.org> <16027.2953.467195.516437@localhost.redhat.com> From: David Carlton Date: Mon, 14 Apr 2003 21:33:00 -0000 In-Reply-To: <16027.2953.467195.516437@localhost.redhat.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-04/txt/msg00295.txt.bz2 On Mon, 14 Apr 2003 15:27:05 -0400, Elena Zannoni said: > David Carlton writes: >> Just for reference, here's a slightly updated version of my namespace >> patch, following Daniel's suggestions. The only real change is that >> it adds a new command "maint cplus first_component" and a new file >> gdb.c++/maint.exp to test it. > Ok, I got around to this finally. It is basically ok, except for the > line between what is c++ and what is symbol table stuff. I think that > more stuff can be pushed into cp-support.c. See below... I have mixed feelings about your comments. My first reaction was the 'using_list' stuff more logically belongs in buildsym.c: it's about building a symtab, after all! So if the only reason to move it to cp-support is to shift the maintenance responsibilities (which is sensible enough, no need for you to look at changes that only affect C++ support), then I'd rather fix the maintenance process: make Daniel a symtab maintainer (he's certainly done enough work on symtabs), or at least allow him to approve C++-specific symtab changes. Having said that, I'm tentatively coming around to your point of view. After all, it's easy enough for me to say that everything related to building symtabs should be in buildsym.c, but if lots of different languages develop their own special needs for the symbol table, then buildsym.c will quickly degenerate into a mess of language-specific special cases. So maybe you're right. And, after all, cp-support.c is a lot smaller than buildsym.c, so it will be a while before it gets too bloated. Daniel, what do you think? A few other issues: > You could tighten the interface a bit, by passing in the name of the > symbol only, instead of the symbol. Yup, good idea. > The struct using_direct could also be made opaque, I think. It can't really be profitably made opaque: it probably looks that way from this patch, but that's only because this patch doesn't actually use struct using_direct, it just constructs them. My next patch will use them in symtab.c. > processing_has_namespace_info: there is one per symtab, yes? > I mean, it is set to 0 only here, just want to make sure. Right. >> + block_set_using (BLOCKVECTOR_BLOCK (blockvector, STATIC_BLOCK), >> + cp_copy_usings (using_list, > Should this function be called something like cp_dup_usings? But you > are freeing the original copy, right? Why do you need to copy it > over? The relevant memory-management issues are a mess. Basically, the list of using directives has to eventually be stored on the objfile's obstack. Unfortunately, that obstack isn't stashed anywhere that buildsym.c (or cp-support.c) can get access to it while constructing using_list. I thought about adding it as an extra argument to start_symtab, but it would have involved making changes to all of start_symtab's callers that I didn't feel entirely comfortable with. So I reluctantly settled on allocating it with xmalloc, and then copying it onto the obstack at a location where we actually know what the obstack is. Thanks a bunch for looking over this; I really appreciate it. I'll check it in once we agree about the proper location of using_list and friends. Actually, the more I think about it, the better cp-support looks as a location: many of the extern functions that I want to add to cp-support are only used by buildsym.c, so that's a good argument for putting those bits of buildsym.c in cp-support.c. David Carlton carlton@math.stanford.edu