Re: [RFA]: Java Inferior Call Take 2

[Jeff Johnston <jjohnstn@redhat.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.
>>