This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: struct environment


On Sat, Sep 07, 2002 at 10:27:58AM -0700, Per Bothner wrote:
> 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.

OK.  At this point, then, I think the thing to do is ignore the Java
dynamic loading for now.  If your changes break compilation of it, we
can #if 0 it out.  Somewhere down the road, after when shared library
support has been multi-arched :), we can redo it that way.

Actually, this has potential - it would be nice to support multiple
dynamic loading mechanisms.  See the XFree86 loader patches on
gdb-patches a while ago...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]