From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20328 invoked by alias); 11 Feb 2013 16:51:44 -0000 Received: (qmail 20320 invoked by uid 22791); 11 Feb 2013 16:51:43 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00,RCVD_IN_HOSTKARMA_NO,UNPARSEABLE_RELAY X-Spam-Check-By: sourceware.org Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 11 Feb 2013 16:51:37 +0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1BGpZii000642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 11 Feb 2013 16:51:36 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1BGpYwZ023551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Feb 2013 16:51:35 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1BGpYGP015071 for ; Mon, 11 Feb 2013 10:51:34 -0600 Received: from dhcp-potsdam-10-165-122-246.de.oracle.com (/10.165.122.246) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 11 Feb 2013 08:51:34 -0800 From: Michael Haupt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: debugging custom array types Message-Id: Date: Mon, 11 Feb 2013 16:51:00 -0000 To: "gdb@sourceware.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2013-02/txt/msg00022.txt.bz2 Dear all, in a research project, I'm generating DWARF debug info for machine code gen= erated from Java. Note that I'm not using gcj. I'm using gdb 7.5, mostly on= Darwin, but the symptoms are the same on Linux. I'm having some trouble with my array types. In particular, there are two p= roblems: 1. I would like to generate DWARF info that allows gdb to display array con= tents. 2. gdb seems to misinterpret valid addresses when they are used in DWARF ex= pressions. Details follow. The internal layout of an array instance is as follows: +0 hub reference (reference to meta-information, e.g., class, vtable, ..= .) +8 length +12 beginning of array contents (offset depends on type, 12 is for char, = for instance) The DWARF I'm generating right now looks as pasted at the end of this messa= ge. This is for Java char arrays with the layout given above. Note the __ar= ray__ member; its type is a plain TAG_array_type that should be interpreted= as embedded. Now, I cannot for the life of me convince gdb to display the contents of th= ose arrays. I'm pretty sure the DWARF info I'm generating has a problem but= cannot figure out what it is. I've been turning things from left to right = for a while now. Here's an excerpt from a debugging session: (gdb) p slot_1_Object $1 =3D java.lang.String@101008910 (gdb) p *slot_1_Object=20 $2 =3D {__hub_reference__: @101000070, value: @101008928, hash32: 0} (gdb) p *slot_1_Object.value=20 Cannot access memory at address 0x101008928 What I'd have expected here is something of the form {__hub_reference__: ..= ., __length__: ..., __array__: {...}}, but gdb complains about the address. Still, (gdb) x/10xb 0x101008928 0x101008928: 0xe8 0x00 0x00 0x01 0x01 0x00 0x00 0x00 0x101008930: 0x0c 0x00 ... so this is definitely not illegal memory. (I can tell from the address = it's a valid heap address.) Grateful for any advice, Michael 0x00005984: TAG_structure_type [16] * AT_name( "char_array" ) ((1)) AT_byte_size( <0xa> 97 23 08 94 04 08 02 1e 23 0c ) AT_sibling( {0x000059bd} ) 0x00005998: TAG_member [10]=20=20 AT_name( "__hub_reference__" ) AT_type( {0x00005c9c} ( Lcom/oracle/svm/core/hub/Dynam= icHub; ) ) AT_data_member_location( +0 ) 0x000059a4: TAG_member [10]=20=20 AT_name( "__length__" ) AT_type( {0x0000002d} ( base ) ) AT_data_member_location( +8 ) 0x000059b0: TAG_member [10]=20=20 AT_name( "__array__" ) AT_type( {0x00005a1e} ( char[] ) ) AT_data_member_location( +12 ) 0x000059bc: NULL ... 0x00005a1e: TAG_array_type [11] * AT_type( {0x0000505b} ( char ) ) ((2)) AT_byte_size( <0x8> 97 23 08 94 04 08 02 1e ) ((3)) AT_data_location( <0x3> 97 23 0c ) AT_sibling( {0x00005a43} ) 0x00005a34: TAG_subrange_type [14]=20=20 AT_type( {0x0000002d} ( base ) ) ((4)) AT_upper_bound( <0x8> 97 23 08 94 04 08 01 1c ) 0x00005a42: NULL The DWARF expressions at ((1))-((4)) each compute the respective values by = pushing the object location, dereferencing the __length__ field, multiplyin= g with the array element size, and possibly adding the array base offset. --=20 Dr. Michael Haupt Principal Member of Technical Staff Phone: +49 331 200 7277, Fax: +49 331 200 7561 Oracle Labs Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14, 14467 Potsdam, Germa= ny