From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13818 invoked by alias); 7 Dec 2006 20:18:28 -0000 Received: (qmail 13805 invoked by uid 22791); 7 Dec 2006 20:18:26 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 07 Dec 2006 20:18:16 +0000 Received: (qmail 9543 invoked from network); 7 Dec 2006 20:18:14 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 7 Dec 2006 20:18:14 -0000 To: =?utf-8?B?56em5beN?= Cc: bjgnu@sunnorth.com.cn, gdb-patches@sourceware.org Subject: Re: [patch] add target Score to GDB References: From: Jim Blandy Date: Thu, 07 Dec 2006 20:18:00 -0000 In-Reply-To: (=?utf-8?B?56em5beNJ3M=?= message of "Thu, 7 Dec 2006 21:39:14 +0800") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00104.txt.bz2 =E7=A7=A6=E5=B7=8D writes: > Jim Blandy wrote on 2006-12-07 03:41:54: >=20=20 >> qinwei@sunnorth.com.cn writes: >> > If we won't open simulator source, can we put simulator libs(11 libs)= =20 > and=20 >> > simstub.c in the dir 'gdb-6.5/sim/score'? >> > If we can, i will send you these libs.=20 >> > Otherwise, i post the patch in the following just containing 'score'=20 > gdb=20 >> > but without simulator. >>=20 >> The GDB source tree cannot contain non-Free software. We give our >> users all the rights to modify and redistribute the software that we >> have, on the condition that they do the same for others; that's the >> founding principle of Project GNU. Including non-free libraries with >> GDB would not follow that principle. >>=20 >> We encourage you to free your simulator; if that's not possible, then >> we'll need to leave the simulator out. > > Hi Jim,=20 > Sorry our company SunNorth doesn't want to open simulator source, please= =20 > leave it out. Okay. >> Does the S+core architecture allow you to mix 32-bit and 16-bit >> instructions? If so, could score_breakpoint_from_pc be simplified to >> always return a 16-bit breakpoint? This would mean that a breakpoint >> inserted at a 32-bit instruction would produce two bytes of garbage >> after the breakpoint, but that's normal; on the i386, GDB uses a >> one-byte breakpoint instruction regardless of the length of the >> instruction it's set at. > > Yes, score supports the mixture of 32-bit and 16-bit instructions. > But score uses the word address to fetch instruction, and then identify i= f=20 > the 32-bits data=20 > is a 32-bit instruction or 2 16-bit instructions. > Only setting 16-bit breakpoint instruction will affect score indentifing= =20 > instruction types > and cause error both on hardware and simulator. I see --- there's much more going on here than there is in most other processors. >> Does score_integer_to_address do exactly the same thing that GCC does >> when the user casts an integer to an address? If they don't, then the >> user could become quite confused when GDB and GCC evaluate their >> expressions differently. > > I didn't see clearly about this hook when i was porting score gdb. > I have seen your NOTES in 'value_as_address'. > The pointer and the address are the same on score target,=20 > and a pointer to a function always points to the entry point address of=20 > that function. > So we don't need to implement this hook. Can i say that? If you don't need to set it to get clean test suite results, then I would definitely recommend leaving it out. >> Future revisions of GCC change the sorts of prologues GDB will >> encounter. If you find yourself investing more time than you expected >> on score_analyze_prologue, consider using the framework in >> prologue-value.h, documented there. > > The next step i will survey other methods such as using=20 > prologue-value.[ch] or=20 > using .eh_frame section and will post new patches. > > Can this patch be checked in first? Using prologue-value certainly isn't required; I just wanted to suggest it. There should be patches to Makefile.in; could you post those? We need to see the complete patch in order to approve it. All changes need a ChangeLog entry. You don't need to say much for score-tdep.c and score-tdep.h; here's the entry for the xtensa port: 2006-11-14 Maxim Grigoriev * NEWS: New port to Xtensa. * Makefile.in: Add dependencies for Xtensa files. * configure.tgt (xtensa*, xtensa*-*-elf*): New. * configure.host (xtensa*-*-elf*): New. * config/xtensa/xtensa.mt: New file. * xtensa-config.c: New file. * xtensa-tdep.h: New file. * xtensa-tdep.c: New file. (I would prefer that the Makefile.in entry actually listed the variables and rules added.) Please keep all lines under 80 characters in length; for example, score_unwind_dummy_id needs to be reformatted. I'm surprised by score_type_needs_double_align --- is it really true that struct types only need double alignment if their *first* member does? Why is that? I'd expect the code for structs and unions to be the same. Other than that, this looks good. Please post a complete patch, generated against the current CVS sources, and with a ChangeLog entry, for a final review, and then we'll get it committed.