From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15417 invoked by alias); 11 Apr 2002 19:55:56 -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 15398 invoked from network); 11 Apr 2002 19:55:55 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 11 Apr 2002 19:55:55 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16vkfn-0004XK-00; Thu, 11 Apr 2002 15:55:59 -0400 Date: Thu, 11 Apr 2002 12:55:00 -0000 From: Daniel Jacobowitz To: Per Bothner Cc: java@gcc.gnu.org, gdb@sources.redhat.com Subject: Re: misc java-related gdb patches Message-ID: <20020411155559.A17324@nevyn.them.org> Mail-Followup-To: Per Bothner , java@gcc.gnu.org, gdb@sources.redhat.com References: <3CB5E975.3050402@bothner.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CB5E975.3050402@bothner.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00171.txt.bz2 On Thu, Apr 11, 2002 at 12:52:21PM -0700, Per Bothner wrote: > I have a bunch of Java-related gdb patches I haven't gotten around > to checking in. They've been sitting in my tree for a while, and > I can't always remember why I did them. Before I try to check > them in, I would appreciate any feedback on whether they make the > "gdb experience" better or worse. > -- > --Per Bothner > per@bothner.com http://www.bothner.com/per/ > 2002-04-10 Per Bothner > > * eval.c (evaluate_subexp_standard): Do overload resolution for Java. > > * infcmd.c (run_command): Reset innermost_block. > > * jv-exp.y (MethodInvocation)): Add preliminary support. > > * valops.c (search_struct_field): Make non-static. > * jv-lang.c (java_class_from_object): De-reference first. > Then call search_struct_field. > > * jv-lang.c: Comment out (using #if DYNAMICS) support for generating > type by reading Class structures from inferior. Needs work. > > * jv-lang.c (evaluate_subexp_java): On UNOP_IND, just smash type. > > * jv-valprint.c (java_value_print): Call value_copy instead of > value_copy. Don't remember why - it may be faster. Typo up there, I assume... > * language.c (unk_lang_create_fundamental_type): Remove. > (unknown_language_defn, auto_language_defn, local_language_defn): > In place of unk_lang_create_fundamental_type use > c_create_fundamental_type. I don't see why this is needed. The language fundamental type hooks should probably all die, IIRC... -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer