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.
>