Re: [RFA]: Java Inferior Call Take 2

Jeff Johnston
2004-06-17T20:52:40Z

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.