From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11902 invoked by alias); 7 Sep 2002 00:19:08 -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 11895 invoked from network); 7 Sep 2002 00:19:07 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 7 Sep 2002 00:19:07 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id g8700ca18758; Fri, 6 Sep 2002 17:00:38 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: tromey@redhat.com Cc: gdb Subject: Re: struct environment References: <87heh2ofia.fsf@fleche.redhat.com> Content-Type: text/plain; charset=US-ASCII From: David Carlton Date: Fri, 06 Sep 2002 17:19:00 -0000 In-Reply-To: <87heh2ofia.fsf@fleche.redhat.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 X-SW-Source: 2002-09/txt/msg00045.txt.bz2 On 06 Sep 2002 17:38:37 -0600, Tom Tromey said: >>>>>> "David" == David Carlton writes: David> * Some sort of growing implementation (necessary for jv-lang.c, David> alas). > I'm not familiar with the code in jv-lang.c. But are you sure it is > really necessary? Could it be that the code there is a workaround > for the existing lack of namespaces? I seem to recall reading that > the gcj support in gdb had such hacks. I don't know either way; > I've just seen this mentioned a few times recently and I wanted to > make sure that the possibility is considered. I would be surprised if it weren't some sort of hack as you suggest. What's going on is that there seems to be a block created whose sole purpose is to contain symbols giving the names of classes. They're all getting plunked in the global namespace, even though they include package names; presumably the package name hierarchy should eventually be reflected in the way that GDB stores that information. One interesting thing that's going on is that the classes in question are all apparently "dynamically loaded". It might be the case that this is somewhat unexpected to the rest of GDB; I'm really not sure. Also, if my dim memory of Java is correct, "global symbols" are kind of rare in Java: probably each file only contains one symbol that's really global in any sense (that symbol being a class whose name is the same as the file), and of course that symbol probably actually lives in a package. So maybe the fact that almost everything in Java lives in a class affects the way that GDB's Java code handles symbols. I dunno. It seems to me that, in the short term, the thing to do is to just deal with making the minimal number of changes to jv-lang.c as is; it's a lot easier to handle it as a special case for now and postpone properly handling it until we're about to start seriously thinking about reworking C++ namespaces. But certainly this should be reworked at an appropriate stage of this process. > I think Per Bothner may be able to answer > questions about this code. He wrote it and he's still involved with > gcj. Good idea; I'll do that on Monday. David Carlton carlton@math.stanford.edu