This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: misc java-related gdb patches
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Per Bothner <per at bothner dot com>
- Cc: java at gcc dot gnu dot org, gdb at sources dot redhat dot com
- Date: Thu, 11 Apr 2002 15:55:59 -0400
- Subject: Re: misc java-related gdb patches
- References: <3CB5E975.3050402@bothner.com>
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 <per@bothner.com>
>
> * 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