This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA]: Java Inferior Call Take 2


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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]