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 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.



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