This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA]: Java Inferior Call Take 2
- From: Jeff Johnston <jjohnstn at redhat dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 17 Jun 2004 16:52:36 -0400
- Subject: Re: [RFA]: Java Inferior Call Take 2
- References: <40A9264C.4060404@redhat.com> <20040617030603.GC23443@nevyn.them.org>
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.