From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3473 invoked by alias); 14 Feb 2013 16:51:05 -0000 Received: (qmail 3463 invoked by uid 22791); 14 Feb 2013 16:51:04 -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, 14 Feb 2013 16:50:57 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r1EGothW032470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Feb 2013 11:50:56 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r1EGos6Z029696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 14 Feb 2013 11:50:55 -0500 From: Tom Tromey To: Michael Haupt Cc: "gdb\@sourceware.org" Subject: Re: debugging custom array types References: <20130211170221.GA16645@host2.jankratochvil.net> <87zjz8ksox.fsf@fleche.redhat.com> Date: Thu, 14 Feb 2013 16:51:00 -0000 In-Reply-To: (Michael Haupt's message of "Thu, 14 Feb 2013 14:27:57 +0100") Message-ID: <87zjz6j0up.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 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/msg00055.txt.bz2 >>>>> "Michael" == Michael Haupt writes: Michael> OK. Is it safe to assume that the VLA work Jan keeps mentioning on Michael> this thread will eventually make it into gdb "proper" (or FSF gdb or Michael> whatever the correct name is)? Is there an idea of how long it might Michael> take? It will go in eventually, but probably in a different form. I don't know how long it will take. It really needs a rewrite. It may help with the problem you are facing, but it won't solve it. That's because the jv-* code in gdb will still be wrong. There's no way to avoid fixing this, unless you want to have arrays that are laid out exactly the same way that gcj does it. For example, see the BINOP_SUBSCRIPT case in jv-lang.c:evaluate_subexp_java. This is the code that handles expressions like "x[5]": address = value_as_address (arg1); address += get_java_object_header_size (exp->gdbarch); read_memory (address, buf4, 4); length = (long) extract_signed_integer (buf4, 4, byte_order); index = (long) value_as_long (arg2); [...] address = (address + 4) + index * TYPE_LENGTH (el_type); This is all pretty bogus; as you can see it pretty much directly knows about array class layout. Gross. I think this code is actually broken right now. At least, a simple test made it seem like array subscripting just doesn't work even for gcj any more. Tom