Re: [RFA]: Java Inferior Call Take 2

[Daniel Jacobowitz <drow@false.org>]

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