From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15046 invoked by alias); 24 Oct 2002 22:07:09 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 15031 invoked from network); 24 Oct 2002 22:07:08 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 24 Oct 2002 22:07:08 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id g9OM71r31752; Thu, 24 Oct 2002 15:07:01 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Andrew Cagney Cc: Elena Zannoni , Jim Blandy , gdb Subject: Re: current namespace game plan References: <15789.43864.432576.737958@localhost.redhat.com> <3DB41A90.4070403@redhat.com> <3DB73276.5000108@redhat.com> From: David Carlton Date: Thu, 24 Oct 2002 15:07:00 -0000 In-Reply-To: <3DB73276.5000108@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: 2002-10/txt/msg00181.txt.bz2 On Wed, 23 Oct 2002 19:36:22 -0400, Andrew Cagney said: > Anyway, to this end I've several idea's: > - Tighten the symtab - core-gdb interface > Here, the objective is to confine the symbol table readers to a very > small arena so that you know exactly how GDB uses them. Since GDB > accesses things though a very tight interface, the symtab code gets > closer to plug-and-play - drop in a new reader and test it. I'm working on doing this in ways that are useful to me. (Well, not quite: I'm interested in the specific task of associating names and symbols, which is less general than "the symbol table readers".) The current situation isn't that bad: what's important to me is that I know how to store data relevant to symbols (actual symbols, as opposed to minimal symbols), how to look up names in various environments (in a particular block, in the global environment, etc.), and how the presence of minimal symbols and partial symbols affects this. The building stuff that's relevant to me is already centralized in buildsym.c. Looking up symbols is in lookup_symbol (well, lookup_symbol_aux) and search_symbol; I've tamed the former enough to make me happy for now (i.e. I can now look up stuff in the global environment by calling lookup_symbol_aux_nonlocal: the innards of that function might be messy, but that's a separate issue), and I'll move on to the latter soon. The presence of partial and minimal symbols certainly affects searches in the global environment; I've been pleased at how effective it's been to encapsulate that all in lookup_symbol_aux_nonlocal, however. > - Push the partial symtab code into the stabs reader. > That way, all the partial symtab bufuddlement isn't in core GDB and > you, and no one else, has to content with it. Gee, thanks, being a stabs expert is really what I have my heart set on right now. :-) Honestly, one of the things on my to do list is to rework how global symbol lookup is handled, which might involve the sort of things you're talking about. Having said that, it keeps on going further and further down my to do list, because I keep on getting surprised at how little the current state of affairs gets in the way of adding namespace support. First, I thought I needed it to do any namespace work; then I thought I needed it to do namespaces properly (as first-class objects); now I'm pretty sure that I'll be able to do namespaces as first class objects without that. I still suspect that I'll want to add iterators to namespace lookups (or to any symbol lookups, really), and it's not at all clear to me that that will work well with the current framework, but it's also not at all clear that it won't. > - eliminate all that symbol table memory mapping stuff Is this xmmalloc and friends? I just noticed that maybe three weeks ago. I was all ready to cut it all out until somebody claimed that Apple uses it. If it's true that it's useful to Apple, then it's not clear to me that it's urgent to cut it out, since I don't think it's particularly causing problems right now. But I like deleting code, so if you can build a consensus that this should go, let me know and I'll be happy to handle it. At the very least, we might as well check with the relevant Apple people: if they don't think its presence in mainline GDB is helpful to them (either because they don't use it after all or because they've made so many changes to GDB to support it that it won't make a difference if we axe it) then we should get rid of it. David Carlton carlton@math.stanford.edu