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 09:35:14 -0600

 >> You'd need to cast it first.
 
 Daniel> Then I don't think GDB would be right to accept it as-is...
 
 Could you offer more justification for this?  I don't think the java
 rules are completely relevant here.  After all, java also has member
 access rules, and gdb ignores those in the interest of providing a
 good user experience.  I think it makes sense for gdb to follow java
 syntax in general, but it doesn't have to be slavish about it.
 
 As for other examples... I note that gdb supplies the "@" operator
 for C/C++, and it also allows you to freely exchange "." and "->" in C.
 I find the latter compelling as prior art in this case.
 
 Daniel> however, a command that printed a value of the run-time type
 Daniel> would be nice, so that your p $1[0] worked.
 
 This leads to the strange result that "p y[0]" is not valid, but
 "p y; p $[0]" is.
 
 This change won't render any current valid code invalid.  So you'll
 still be able to cut and paste java expressions into gdb.  It will
 just make gdb more useful to people who do a lot of java debugging.
 
 There are other examples of this problem, btw.  It isn't limited to
 arrays.  For instance, if I have something declared as Object, I can't
 print any of its fields without casting it to the correct type (which
 gdb already knows).
 
 Tom


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