From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17904 invoked by alias); 15 Mar 2007 02:03:39 -0000 Received: (qmail 17724 invoked by uid 22791); 15 Mar 2007 02:03:38 -0000 X-Spam-Check-By: sourceware.org Received: from hq.tensilica.com (HELO mailapp.tensilica.com) (65.205.227.29) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 15 Mar 2007 02:03:33 +0000 Received: from localhost ([127.0.0.1]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1HRfJS-0001yj-SL; Wed, 14 Mar 2007 18:03:30 -0800 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07383-02; Wed, 14 Mar 2007 18:03:30 -0800 (PST) Received: from maxim_fc5.hq.tensilica.com ([192.168.11.68]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1HRfJS-0001yd-G2; Wed, 14 Mar 2007 18:03:30 -0800 Message-ID: <45F8A972.7090406@hq.tensilica.com> Date: Thu, 15 Mar 2007 02:03:00 -0000 From: Maxim Grigoriev User-Agent: Thunderbird 1.5.0.9 (X11/20070102) MIME-Version: 1.0 To: gdb@sourceware.org, Bob Wilson , Daniel Jacobowitz Subject: Re: GDB (mis)behavior depends on DWARF DW_TAG_compile_unit data References: <45F5B929.3050406@hq.tensilica.com> <20070312204857.GA20515@caradoc.them.org> <45F5C0D3.90002@hq.tensilica.com> <20070312212405.GM14401@adacore.com> <45F5CBFD.3020109@hq.tensilica.com> <20070312215821.GA24531@caradoc.them.org> In-Reply-To: <20070312215821.GA24531@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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: 2007-03/txt/msg00206.txt.bz2 I found what the problem is. It's strictly Tensilica-compiler-specific. I suggest we discuss it on the gdb-patch list since I already tried to provide a patch to fix this issue. If we end up with understanding that compiler should be fixed then my GDB patch should be modified to recognize inconsistent DWARF and issue a warning instead of printing misleading error messages (like it does now). -- Maxim Daniel Jacobowitz wrote: > On Mon, Mar 12, 2007 at 02:54:05PM -0700, Maxim Grigoriev wrote: > >> Let me find out what it is and get back to you with my conclusions. It's >> still can be >> important for GDB in terms of better handling bad DWARF data. >> > > Thanks - I completely agree. It's not the obvious problem, but > whatever it is, we should fix it if we can. > >