Re: [RFC]: java inferior function call support

[Daniel Jacobowitz <drow@false.org>]

On Tue, Mar 23, 2004 at 05:12:35PM -0500, Jeff Johnston wrote:
> Daniel Jacobowitz wrote:
> >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.
> >
> 
> They are not compatible.  I have been discussing this for a while with 
> Andrew Haley who maintains gcj.
> 
> I have included a unit-test case: Property.java.
> 
> Compile it:
> 
>   gcj -g --main=Property Property.java
> 
> run gdb:
> 
>   b Property.main (java.lang.String[])
>   next (until you have passed the creation of x)
>   call x.print(22)
>   call x.dothat(23)
> 
> print is a static member function
> dothat is a non-static member function
> 
> I have included a similar C++ version of Property (test.cxx) and I have 
> included the two debug info outputs.  You will note in C++, the Property 
> class has a _vptr entry.  This _vptr entry does not exist in Java.  Andrew 
> suggested that gdb find the vtable for Java as I have implemented it.

No, Java just calls it something else:

 <2><d7c>: Abbrev Number: 11 (DW_TAG_member)
     DW_AT_name        : vtable
     DW_AT_type        : <2323>
     DW_AT_data_member_location: 2 byte block: 23 0 (DW_OP_plus_uconst: 0; )
     DW_AT_artificial  : 1
     DW_AT_accessibility: 3     (private)

That's the vtable for Object, and thus for classes deriving from Object also.

If you make the debug readers recognize this as the vtable for Java symbols,
then the existing machinery should work, without having to do all this
grubbing around in the v3 ABI code.

> >>       * 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.
> >
> 
> When I create the array type, I need to give it a range.  I specify -1 for 
> the upper-bound as C++ does for the regular vtable.  The problem is that 
> C++ and C have the luxury of not doing range checking in value_subscript 
> because they are "c-style" array languages.  For Java, it checks the 
> upper-bound and issues a warning message about "subscript out of range".  I 
> did not want the message to be issued in this particular case because I 
> trust the voffset value.  I attempted an experiment to give a large default 
> value for the upper-bound but the call to value_subscript ends up 
> allocating storage which is definitely not a good thing.  The simplest 
> answer was I wanted to eliminate range checking on the call which I do by 
> specifying "c-style" arrays.  I made that a parameter of value_subscript_1 
> and had value_subscript call it with the language value.

OK, now I understand what you're doing.  This should not happen if the
vtable is marked lazy... which it is.  I spent some time tracing and
could not find out why this would happen.

Either that should be fixed (or at least understood better), or we
may want to allow -1 to indicate "unspecified upper bound" for
non-c-style languages also.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer