From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8911 invoked by alias); 17 Jun 2004 20:52:40 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 8901 invoked from network); 17 Jun 2004 20:52:38 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 17 Jun 2004 20:52:38 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i5HKqce1010954 for ; Thu, 17 Jun 2004 16:52:38 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i5HKqc018567; Thu, 17 Jun 2004 16:52:38 -0400 Received: from touchme.toronto.redhat.com (IDENT:postfix@touchme.toronto.redhat.com [172.16.14.9]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id i5HKqbtn017514; Thu, 17 Jun 2004 16:52:37 -0400 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id C208F800326; Thu, 17 Jun 2004 16:52:36 -0400 (EDT) Message-ID: <40D20494.2020608@redhat.com> Date: Thu, 17 Jun 2004 20:52:00 -0000 From: Jeff Johnston User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA]: Java Inferior Call Take 2 References: <40A9264C.4060404@redhat.com> <20040617030603.GC23443@nevyn.them.org> In-Reply-To: <20040617030603.GC23443@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-06/txt/msg00422.txt.bz2 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.