Re: [RFA]: Java Inferior Call Take 2

[Jeff Johnston <jjohnstn at redhat dot com>]

Ping.

Jeff Johnston wrote:
> Daniel Jacobowitz wrote:
>
> > 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.
>
> Ok, I figured out what piece I left out and have remade the patch.  I 
> can't remember where we are on this regarding the workaround for gcc 
> debug-info, but at least you will be able to run the test with the full 
> functionality now. Please let me know what is needed next as I want to 
> move this forward.
>
> -- Jeff J.
>
> > > > - 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 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.