Re: [RFA]: Java Inferior Call Take 2

Jeff Johnston
2004-07-26T19:49:32Z

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