From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28984 invoked by alias); 10 May 2012 13:34:00 -0000 Received: (qmail 28976 invoked by uid 22791); 10 May 2012 13:33:59 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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, 10 May 2012 13:33:45 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q4ADXhkC016266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 May 2012 09:33:43 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q4ADXfV7030924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 10 May 2012 09:33:42 -0400 From: Tom Tromey To: Tomasz Grobelny Cc: Sergio Durigan Junior , Subject: Re: sun compiler and gdb References: <25b0084e43f4d35410c8dff55a3be61d@192.168.5.248> <543302446b67dbf68e8cedb69a197d77@192.168.5.248> <871umtrtab.fsf@fleche.redhat.com> Date: Thu, 10 May 2012 13:34:00 -0000 In-Reply-To: (Tomasz Grobelny's message of "Thu, 10 May 2012 00:57:56 +0200") Message-ID: <87havoqhxm.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.95 (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: 2012-05/txt/msg00039.txt.bz2 >>>>> "Tomasz" == Tomasz Grobelny writes: Tom> If you have a small test case, a dump of the DWARF information might Tom> prove helpful. If you only have a large test case, then something more Tom> selective could help. Tomasz> A trivial test case attached. Compiled with: Tomasz> CC: Sun C++ 5.11 SunOS_sparc 2010/08/13 I think it is a compiler bug. The DWARF (from your second posting) looks like: <1><13b39>: Abbrev Number: 115 (DW_TAG_imported_declaration) <13b3a> DW_AT_import : <0x0> [Abbrev Number: 0] I don't think this is a valid DW_AT_import. Tomasz> But still the most important question for me is: is it supposed Tomasz> to work? I understand that there may be bugs on either side, but Tomasz> does the general design of dwarf format/compiler/gdb allow for Tomasz> debugging code generated with sun studio compiler using gdb? -- Yes, it can work. The overall design is sound. GDB even works around compiler bugs. This, however, can only happen when an interested party patches GDB to do so. In this case you could perhaps add some code to dwarf2read.c:read_import_statement, and maybe a new variant of follow_die_ref_or_sig, to handle this bogus DW_AT_import. After that you'd have to try again and see what other bugs crop up. One way to fully test the DWARF reader is to run with -readnow. This will cause full expansion of all CUs -- so any problems will be caught immediately at startup. Tom