This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA]: Java Inferior Call Take 2
On Wed, Jun 23, 2004 at 05:55:07PM -0400, Jeff Johnston wrote:
> Daniel Jacobowitz wrote:
> >On Wed, Jun 23, 2004 at 12:05:59PM +0100, Andrew Haley wrote:
> >
> >>This patch is now in mainline. Is there anything else you need?
> >
> >
> >Yes. Two sets of questions left, one for Jeff and one [plus a little
> >bit] for you...
> >
> >
> >Jeff, one test still fails: calling addprint. I think this is mostly a
> >GDB problem rather than GCC. Before starting the program I see this:
> >
>
> Let me take a look at it. It is not failing in my all-patches-applied
> build. Perhaps in splitting the patches up, I screwed up and missed
> something.
Thanks.
> > - Should we suppress jvclass and <clinit> the way we do for C++
> > artificial methods?
> >
>
> Perhaps remove <clinit>, but jvclass() is the constructor. There could be
> multiple constructors and as an end-user, I would want to see the various
> prototypes. I can't speak for what C++ does.
In C++, the debug information marks whether a constructor was written
by the user (i.e. the type really contains a constructor) or by the
compiler (i.e. implicit). I imagine Java's debug information has the
same thing. For minimum confusion, we choose not to print the
artificial methods in C++ types; I think we should do the same for
Java.
(This shouldn't affect breakpointing it for users who know the
constructor exists.)
>
> > - Why is it java::lang::Object instead of java.lang.Object?
> >
>
> This is because we use the C++ class_name_from_physname() function which is
> C++-specific. I had submitted another patch that was put out at the same
> time which I don't think anybody has looked at which fixes this problem.
> It has to do with adding class_name_from_physname to the language vector.
OK, thanks. I reviewed it on the 16th. I failed to CC you on the
message, though. Likewise the tab completion patch.
> > - Why did printing of the type change? There's only one definition
> > of jvclass in the debug info, and it's marked Java.
> >
>
> There are checks in the code based on current language. The current
> language does not start as java. If you manually change it via set
> language java, you will see the same results before and after.
Bleeeeeeech. Thanks for explaining; definitely not your problem, but
definitely a bug. If we're printing a type we ought to be using the
type's language.
--
Daniel Jacobowitz