From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11556 invoked by alias); 22 Sep 2006 23:59:43 -0000 Received: (qmail 11546 invoked by uid 22791); 22 Sep 2006 23:59:42 -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; Fri, 22 Sep 2006 23:59:39 +0000 Received: from localhost ([127.0.0.1] ident=amavis) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1GQuvg-0002I6-Pl; Fri, 22 Sep 2006 16:59:36 -0700 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07893-03; Fri, 22 Sep 2006 16:59:36 -0700 (PDT) Received: from maxim_fc3.hq.tensilica.com ([192.168.11.68]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1GQuvg-0002I0-Ca; Fri, 22 Sep 2006 16:59:36 -0700 Message-ID: <451478E8.3060603@hq.tensilica.com> Date: Fri, 22 Sep 2006 23:59:00 -0000 From: Maxim Grigoriev User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Jim Blandy CC: Maxim Grigoriev , gdb-patches@sources.redhat.com, Bob Wilson , chris Zankel Subject: Re: Xtensa port References: <45142A88.7000805@hq.tensilica.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-09/txt/msg00154.txt.bz2 Hi Jim, > I haven't looked at the code closely, but I have a few questions. > > - Where does xtensa-config.h come from? > It's been already submitted as a part of Xtensa BFD. It comes from /cvs/src/src/include/xtensa-config.h > - Does xtensa-config.c need to be listed in ALLDEPFILES as well? > You're right, thank you. I modified Makefile.in. So it will be reflected in the corrected patch I send after all the suggestions are handled properly. > - I don't see anything that actually plugs in xtensa-linux-tdep.o. > Should that be kept out until the linux target is ready? > I don't know. I was thinking in advance. The next update is supposed to be submitted shortly after the first one. > - In your DejaGnu config files, there is a way to tell GDB not to run > tests that depend on the inferior being able to do I/O; this is used > to run the tests against embedded systems that don't implement the > semi-hosting protocol packets, like yours. Look for uses of > 'gdb_skip_stdio_test'. > Some of the functionality covered in "stdio.h" is implemented on the level of FILEIO protocol, which I treat as a subset of GDB remote protocol. Tensilica OCD daemon supports FILEIO. And, I introduced a target library, which, when linked with a stand-alone Xtensa program, allows to use FILEIO through OCD. So I think using "gdb_skip_stdio_test" would be too restrictive. > - Can you explain more about the differences between the > Xtensa-generated DWARF and what GDB expects? Ideally, GDB should > accept DWARF from any compiler, but because DWARF is so flexible > it's easy for inappropriate expectations to creep in. > In most such cases, I'd treat Tensilica compiler misbehavior as a bug. As a matter of fact, many of these cases are already filed as "Problem Reports" against compiler in Tensilica GNUTS. Examples: 1) Wrong line-number information for multi-line source code: 1:if (a 2: && b 3: && c) the debugging information for the if-clause points to line 3 in XCC. 2) Sometimes, Tensilica compiler drops type qualifiers, such as volatile and const. 3) In some cases, typedef'd types have no debugging information. Example: typedef int t_int; int main(void) { return 0; } 4) When the program is compiled with "-O2 -g", there are issues with scoping for variables; 5) Tensilica compiler does not always add a file information in the debugging information; There is more stuff like this, but this is all about our compiler, which is probably not interesting for the GDB community. I hope I answered your questions. -- Maxim