Re: struct environment

[Per Bothner <per@bothner.com>]

David Carlton wrote:
> One interesting thing that's going on is that the classes in question
> are all apparently "dynamically loaded".

Yes.  This code date back the the very early days of gcj, when we were
basing it on the Kaffe run-time, which was JIT-based.  Even the days
it is possible for a class to be generated on-the-fly, or loaded from
a .jar file containing bytecodes.  Such a class will not have dwarf
or other static symbols.  So this was an attempt to extract the type
information from a class from the run-time type information for a
class instead of or in addition to the static symbols.

Such an attempt runs into various assumptions of gdb, such as how
symtabs are managed and reclaimed, so it was never very solid.
We can't debug interpreted bytecode anyway, so it's not much use.
Feel tree to tear this code out, but keep in mind that new Java
classes may be created on the fly.

I think the correct way to handle on-the-fly Java classes is to
use a model similar to dynamically linked libraries.  In both
cases a program can execute library functions that bring in new
code and new global symbols.  The main difference is that there
may be many more Java classes that are dynamically loaded then
the number of shared libraries, which may effect the strategy
used.  Though if most classes are pre-compiled, we're talking
at most hundreds, rather than thousands.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/