Re: [RFC]: java inferior function call support

[Daniel Jacobowitz <drow@false.org>]

On Tue, Mar 23, 2004 at 02:03:31PM -0500, Jeff Johnston wrote:
> The following patch adds initial support for simple java inferior calls. 
> Standard calls are either calling a member function of a variable which is 
> a class or a static member function of a class by name.  There are a number 
> of complex scenarios that do not work, but this patch lays the groundwork 
> for supporting them in the future.
> 
> There a few differences between Java and C++ that require handling.  First 
> of all, the Java debug info for a member has a fully qualified name 
> including prototype.  There is an open bugzilla bug against gcj for this, 
> however, I think some rethinking may be required.  In a recent C++ bug, I 
> have found that C++ does not correctly list or properly allow selection of 
> multiple constructors with varying prototypes.  It gets the line numbers 
> and prototypes all wrong. Java, surprisingly, does the right thing.  It 
> lists the correct line numbers and prototypes, and selection works 
> properly.  The fully qualified member name does interfere with tab 
> completion so there is work required.  I have dealt with the gcj problem by 
> parsing out the qualifiers and prototype for a Java member name.
> 
> Another key difference is how the vtable is structured.  For Java, the 
> vtable is an array of function pointers and is located by the first word of 
> every class. It is much more complex for C++ so I have forked the logic 
> that accesses the vtable in gnu-v3-abi.c.
> 
> Ok to commit or comments?

Could we have a test case, also?

The C++ constructors problem you saw is probably related to the
existing bugs with cloned functions, and also to the lousy debug
information that GCC emits for them.

I'm not at all sure about the vtable changes.  They should be
compatible, because gcj does try to follow the C++ ABI.  If you'll send
a testcase, I'll take another look and see what I'm missing.

>         * valarith.c (value_subscript_1): New function that takes
>         c_style as argument.
>         (value_subscript): Change to call value_subscript_1.

Why is this necessary?  You're using a gdb-created type anyway, you
shouldn't need to change anything in value_subscript if you're
subscripting with the right indices.

>         * symtab.c (lookup_symbol): Support Java demangling.

We're trying to move away from this; what breaks without it?


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer