From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5339 invoked by alias); 7 Feb 2013 18:47:16 -0000 Received: (qmail 5291 invoked by uid 22791); 7 Feb 2013 18:47:15 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_GC X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 07 Feb 2013 18:47:06 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r17Il5xs030043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Feb 2013 13:47:05 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r17Il31i020522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 7 Feb 2013 13:47:04 -0500 From: Tom Tromey To: Michael Haupt Cc: java@gcc.gnu.org Subject: Re: gcj and debugging References: Date: Thu, 07 Feb 2013 18:47:00 -0000 In-Reply-To: (Michael Haupt's message of "Fri, 1 Feb 2013 16:07:17 +0100") Message-ID: <87y5f0ufko.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org X-SW-Source: 2013-02/txt/msg00003.txt.bz2 >>>>> "Michael" == Michael Haupt writes: Michael> in a research project, I'm generating DWARF debugging info for machine Michael> code generated from Java. I looked at some of the DWARF debug info Michael> generated by gcj (including that contained in libgcj.so). I think the first thing to realize is that the gdb support for Java was all written to target gcj specifically, and also written long ago and then barely updated. It isn't very general or done the way it would be done now. It was never updated for the gcj binary compatibility ABI. Michael> Java arrays are all merely declared in the DWARF; structural Michael> information about Java array objects is not given. In libgcj's Michael> array.h, there are two classes, __JArray and JArray (inheriting Michael> from __Jarray), that hold a length field and, in addition, a T* Michael> array[0]. Michael> The debug info for libgcj does not contain any structural information Michael> about these two classes. Michael> How does gdb determine that there is a length field, and how many Michael> elements there are if the length is assigned dynamically? I reckon the Michael> latter can be done by describing the length as a DWARF exprloc, but Michael> the description is nowhere to be found. I thought things like "print array[0]" used to work, but even that seems to fail for me now. There is definitely some code for this in gdb, see jv-valprint.c:java_value_print. It seems to know a bit about array layout and then goes from there (though the code looks somewhat bogus to me...). See also jv-lang.c:evaluate_subexp_java for the code that tries to do array subscripting. Without debugging more I couldn't say why it is broken. Michael> How does the DWARF description of a Java array look? Michael> Is this generated at run-time somehow? Michael> Do gcj-generated binaries and gdb interact in some other ways than Michael> through DWARF when it comes to meta-info exchange? I believe gdb can also read some of the gcj runtime metadata and construct type information from this. The code here seems pretty minimal though. Michael> Likewise, how does gdb know how to display a java.lang.String as a, Michael> well, string? gdb has special code for this. It looks for a type named "java.lang.String" and then knows what fields it has. Yucky. Nowadays I'd be more tempted to implement string-printing using Python. _Jv_Utf8Const could be handled this way too. Tom