Re: [RFA]: Java Inferior Call Take 2

[Jeff Johnston <jjohnstn@redhat.com>]

Daniel Jacobowitz wrote:
> On Mon, May 17, 2004 at 04:53:32PM -0400, Jeff Johnston wrote:
> 
>>This is the reworked java inferior call patch.  My previous attempt tried 
>>to modify the gdb v3 abi code to handle missing debug information from gcj. 
>>After a couple of gcc patches from Andrew Haley, the gnu-v3-abi.c code 
>>doesn't require any tampering.
>>
>>I had to enhance dwarf2read.c to handle the java vtable name (which is 
>>vtable) and to modify C++-only code to handle java syntax for class names.
>>
>>I have included a test case.
>>
>>Ok to commit?
> 
> 
> First of all, it doesn't work for me; I'm guessing that's because I
> have gcj 3.3 installed.  Are the GCC changes in any released version of
> GCC yet, so that I can add appropriately versioned XFAILs?
>

I am using current gcc sources because Andrew Haley only recently added the 
fixes.  It has to be post 3.4.0 which is the last release but prior to Andrew's 
patches.

> 
>>	* valarith.c (value_subscript): Treat an array with upper-bound
>>	of -1 as unknown size.
> 
> 
> I still don't understand why this change is necessary, i.e. why
> providing a large upper bound causes the whole memory region to be
> loaded from the inferior.  That should not happen.
> 
>

The change "is" needed or the warning gets issued in value_subscript.  C and C++ 
get away with it because of c_style_arrays.

The other solution is to change the range of the virtual_functions array to have 
a large value for an upperbound, but that requires a change to gnu-v3-abi.c 
which "you asked me not to change".

static void *
build_gdb_vtable_type (struct gdbarch *arch)
.
.
.
   /* void (*virtual_functions[0]) (); */
   FIELD_NAME (*field) = "virtual_functions";
   FIELD_TYPE (*field)
     = create_array_type (0, ptr_to_void_fn_type,
                          create_range_type (0, builtin_type_int, 0, -1));
   FIELD_BITPOS (*field) = offset * TARGET_CHAR_BIT;
   offset += TYPE_LENGTH (FIELD_TYPE (*field));
   field++;

Changing the -1 above to INT_MAX/4 results in a virtual memory exhausted error 
when making a virtual function call.  Backtracing, we see:

(outer) bt
#0  internal_error (
     file=0x822e740 
"/home/jjohnstn/gdb-patches/inf-call-java-may12-2004/src/gdb/utils.c", 
line=1036, string=0x822e934 "virtual memory exhausted.")
     at /home/jjohnstn/gdb-patches/inf-call-java-may12-2004/src/gdb/utils.c:835
#1  0x08082a0a in nomem (size=-2147483564)
     at /home/jjohnstn/gdb-patches/inf-call-java-may12-2004/src/gdb/utils.c:1036
#2  0x08082a42 in xmmalloc (md=0x0, size=2147483732)
#3  0x08082b27 in xmalloc (size=2147483732)
     at /home/jjohnstn/gdb-patches/inf-call-java-may12-2004/src/gdb/utils.c:1128
#4  0x080dcd2d in allocate_value (type=0x8358b48)
     at /home/jjohnstn/gdb-patches/inf-call-java-may12-2004/src/gdb/values.c:86
#5  0x080e4938 in value_at_lazy (type=0x8358b48, addr=134521984, sect=0x0)
     at /home/jjohnstn/gdb-patches/inf-call-java-may12-2004/src/gdb/valops.c:485
#6  0x081878f0 in gnuv3_virtual_fn_field (value_p=0xbfffb28c, f=0x836da8c,
     j=0, type=0x834ab18, offset=0)
     at /home/jjohnstn/gdb-patches/inf-call-java-may12-2004/src/gdb/gnu-v3-abi.c:332


>>@@ -3101,7 +3112,29 @@ dwarf2_add_member_fn (struct field_info 
>>   /* Get name of member function.  */
>>   attr = dwarf2_attr (die, DW_AT_name, cu);
>>   if (attr && DW_STRING (attr))
>>-    fieldname = DW_STRING (attr);
>>+    {
>>+      /* Note: C++ and Java currently differ in how the member function
>>+         name is stored in the debug info.  For Java, the member name is
>>+	 fully qualified with prototype while C++ just has the member
>>+	 name.  To get the Java member name, we strip off any dot qualifiers
>>+	 and remove the trailing prototype.  */
> 
> 
> Other changes have been made to gcj's debug output in order for this to
> work; wouldn't this be a good time to fix the above?  No one's given a
> reason that I recall for GCJ to abuse DW_AT_name in this fashion.
> 

Perhaps, but perfection is always an on-going goal.  IMO, this isn't worth 
holding up the patch while we discuss this with gcc.  The code certainly is not 
a problem for anybody to maintain and I am perfectly willing to put a FIXME note 
for the time-being.

-- Jeff J.