This is the mail archive of the gdb-prs@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: java/1413: gdb loses java type information


The following reply was made to PR java/1413; it has been noted by GNATS.

From: Tom Tromey <tromey@redhat.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: java/1413: gdb loses java type information
Date: 09 Oct 2003 13:18:59 -0600

 >> This is pretty unusual though.  I don't know of a situation like this
 >> in libgcj, for instance -- whereas I run into the other debugging
 >> problem very frequently.
 
 Daniel> However - here's my concern - that is exactly the case where this is a
 Daniel> problem.  If I expect to get the dynamic type's field, and due to a
 Daniel> programming error I've omitted a cast, so I get the static type's
 Daniel> field, and yet GDB prints out the dynamic type's member.... oops!
 
 Sure, we'd want to preserve the cut-and-paste property.
 This can easily be done by trying the declared type first.
 
 I don't really consider this corner case that strong of an argument
 against.  The fact is, I've never run into this when debugging java
 code.  On the other hand, I run into this other limitation all the
 time, more than half of all debugging sessions.
 
 Another approach would be to change gdb not to print the runtime type
 at all.  This would make gdb less useful, in a sense, but at least I
 wouldn't consistently be confused and frustrated by it.
 
 Tom


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