From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20508 invoked by alias); 7 Sep 2002 17:32:31 -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 20496 invoked from network); 7 Sep 2002 17:32:30 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 7 Sep 2002 17:32:30 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17nkNG-0006Gq-00; Sat, 07 Sep 2002 13:32:02 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17njRA-0007UW-00; Sat, 07 Sep 2002 13:32:00 -0400 Date: Sat, 07 Sep 2002 10:32:00 -0000 From: Daniel Jacobowitz To: Per Bothner Cc: David Carlton , gdb Subject: Re: struct environment Message-ID: <20020907173200.GA28687@nevyn.them.org> Mail-Followup-To: Per Bothner , David Carlton , gdb References: <87heh2ofia.fsf@fleche.redhat.com> <3D7A371E.2070806@bothner.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D7A371E.2070806@bothner.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-09/txt/msg00048.txt.bz2 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