Re: [RFA]: Java Inferior Call Take 2

Jeff Johnston
2004-06-23T21:55:09Z

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.

> (gdb) ptype jvclass
> type = class jvclass : public java::lang::Object {
> public:
> static int k;
>
> static void addprint(int, int, int);
> virtual int addk(int);
> }
>
> Then, after starting it:
> (gdb) ptype jvclass
> type = class jvclass extends java::lang::Object {
> public static int k;
>
> void addprint(int, int, int);
> int addk(int);
> jvclass();
> void <clinit>();
> }
>
> - 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.

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

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

> [Andrew, I notice that we've lost the 'static' here. There's nothing
> in the dwarf output to express it, so this is a GCC problem.]
>
> (gdb) p jvclass.addprint(1,2,3)
> There is no field named addprint
>
> Calling x.addprint(1,2,3) works. This is because x.addprint goes
> through value_struct_elt to value_fn_field, which falls back to
> lookup_minimal_symbol if lookup_symbol fails, and jvclass.addprint goes
> through value_aggregate_elt, which doesn't. lookup_symbol fails
> because the demangling code in it is specific to C++. So does this
> test pass for you, and if so what happens differently? Do we need to
> extend the hack in lookup_symbol for Java?
>
> It may be that fixing the missing static in the debug info fixes this
> too.
>
>
> The other question: I looked at fixing the debug info to print field
> names correctly. The reason it's wrong is that dwarf2out uses the
> decl_printable_name langhook. Java doesn't use the second argument,
> which the common code assumes is verbosity. Common code always passes
> '2', which matches what Java's does, except in three places: mudflap
> (???), the C tree pretty printer, and this call in dwarf2out used to
> set the name of decls. Java mostly passes 0 since it knows the value
> is ignored. Any reason not to fix up the Java frontend to pass 2,
> extend the function to handle smaller values, and thus correct the
> debug output?
>
> The only problem I see with this is that class names will lose scope
> information, which is nominally right... except that we don't output
> anything describing packages. Perhaps we should use DW_TAG_namespace
> for that but making it work will be a bit of a stretch. Anyway, for
> the moment GDB will work OK without this; it gets it from the demangled
> names.
>