This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: java/1413: gdb loses java type information
- From: Tom Tromey <tromey at redhat dot com>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 9 Oct 2003 15:48:04 -0000
- Subject: Re: java/1413: gdb loses java type information
- Reply-to: Tom Tromey <tromey at redhat dot com>
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