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 19:38:00 -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 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