Re: struct environment

[David Carlton <carlton@math.stanford.edu>]

On 06 Sep 2002 17:38:37 -0600, Tom Tromey <tromey@redhat.com> said:
>>>>>> "David" == David Carlton <carlton@math.stanford.edu> 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 <bothner@bothner.com> 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