From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14612 invoked by alias); 12 Mar 2007 21:54:18 -0000 Received: (qmail 14602 invoked by uid 22791); 12 Mar 2007 21:54:17 -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; Mon, 12 Mar 2007 21:54:11 +0000 Received: from localhost ([127.0.0.1]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1HQsT0-00026K-Aw; Mon, 12 Mar 2007 13:54:06 -0800 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08017-01; Mon, 12 Mar 2007 13:54:06 -0800 (PST) Received: from maxim_fc5.hq.tensilica.com ([192.168.11.68]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1HQsSz-00026E-Sv; Mon, 12 Mar 2007 13:54:05 -0800 Message-ID: <45F5CBFD.3020109@hq.tensilica.com> Date: Mon, 12 Mar 2007 21:54:00 -0000 From: Maxim Grigoriev User-Agent: Thunderbird 1.5.0.9 (X11/20070102) MIME-Version: 1.0 To: Joel Brobecker CC: Maxim Grigoriev , gdb@sourceware.org, Bob Wilson , Marc Gauthier 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> In-Reply-To: <20070312212405.GM14401@adacore.com> Content-Type: text/plain; charset=us-ascii; 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/msg00174.txt.bz2 Now I'm getting convinced more and more that this is Tensilica compiler's problem. It could be not that trivial as I thought in the beginning. I didn't actually compare executables from different compilers running them under latests GDB's control. Instead, I was comparing DWARF data, specifically, "DWARF DW_TAG_compile_unit" tag. That's why I missed the point that Xtensa-specific GDB misbehavior has nothing to do with "DWARF DW_TAG_compile_unit" entry ( which looks the same across all the compilers ). It has to be something else. 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 much for your valuable input on this. It really helps. -- Maxim Joel Brobecker wrote: >> If you think it's a generic GDB problem I can fix it. I have to fix it >> anyway on Xtensa GDB. I don't see how it can be Xtensa-specific. >> Xtensa GCC compiler DWARF is consistent with native GCC 4.1.1 compiler >> on my Linux box. So if this is a compiler problem ( which I doubt ) >> it seems to be pretty generic. >> > > With the information you have given us, all I can say is that GDB > should be able to handle the situation, so we do have a bug somewhere. > Whether it is in GCC or GDB is still an open question as far as I can > tell. > > Have you checked the line-table as well in both cases? There is > a very convenient command that gives you the list of lines known > by GDB for any given file: -symbol-list-lines. It's a MI command, > but you should be able to use it from the GDB prompt using > "interpreter-exe mi -symbol-list-lines" followed by the filename. > >