From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12805 invoked by alias); 13 Feb 2013 17:52:07 -0000 Received: (qmail 12794 invoked by uid 22791); 13 Feb 2013 17:52:07 -0000 X-SWARE-Spam-Status: No, hits=-6.4 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 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; Wed, 13 Feb 2013 17:52:00 +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 r1DHpxZ4016532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Feb 2013 12:51:59 -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 r1DHpwgH016693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 13 Feb 2013 12:51:58 -0500 From: Tom Tromey To: Michael Haupt Cc: "gdb\@sourceware.org" Subject: Re: debugging custom array types References: <20130211170221.GA16645@host2.jankratochvil.net> Date: Wed, 13 Feb 2013 17:52:00 -0000 In-Reply-To: (Michael Haupt's message of "Wed, 13 Feb 2013 11:50:34 +0100") Message-ID: <87zjz8ksox.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/msg00048.txt.bz2 >>>>> "Michael" == Michael Haupt writes: Michael> Is there documentation somewhere that explicates which pieces of DWARF Michael> gdb supports out of the box? There isn't. We've made some effort over the last few years to support more of DWARF, but there are still holes (some mentioned in bugzilla). Usually the holes are either because the implementation is very hard (the VLA work falls into this category) or because no compiler has ever been seen to emit the DWARF in question. Michael> DW_OP_push_object_address This one is still unimplemented, one of the few remaining DW_OP_ holes. Tom