From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18975 invoked by alias); 7 Sep 2002 17:26:43 -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 18968 invoked from network); 7 Sep 2002 17:26:40 -0000 Received: from unknown (HELO bothner.com) (216.102.199.253) by sources.redhat.com with SMTP; 7 Sep 2002 17:26:40 -0000 Received: from bothner.com (eureka.bothner.com [192.168.1.9]) by bothner.com (8.11.6/8.11.6) with ESMTP id g87HYLu25660; Sat, 7 Sep 2002 10:34:22 -0700 Message-ID: <3D7A371E.2070806@bothner.com> Date: Sat, 07 Sep 2002 10:26:00 -0000 From: Per Bothner User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020814 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Carlton CC: gdb Subject: Re: struct environment References: <87heh2ofia.fsf@fleche.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00047.txt.bz2 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/