From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31551 invoked by alias); 6 Dec 2006 19:41:16 -0000 Received: (qmail 31538 invoked by uid 22791); 6 Dec 2006 19:41:14 -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; Wed, 06 Dec 2006 19:41:08 +0000 Received: (qmail 7552 invoked from network); 6 Dec 2006 19:41:05 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 6 Dec 2006 19:41:05 -0000 To: qinwei@sunnorth.com.cn Cc: bjgnu@sunnorth.com.cn, gdb-patches@sourceware.org Subject: Re: [patch] add target Score to GDB References: From: Jim Blandy Date: Wed, 06 Dec 2006 19:41:00 -0000 In-Reply-To: (qinwei@sunnorth.com.cn's message of "Wed, 6 Dec 2006 13:34: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=us-ascii 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/msg00071.txt.bz2 qinwei@sunnorth.com.cn writes: > If we won't open simulator source, can we put simulator libs(11 libs) and > simstub.c in the dir 'gdb-6.5/sim/score'? > If we can, i will send you these libs. > Otherwise, i post the patch in the following just containing 'score' gdb > but without simulator. 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. We encourage you to free your simulator; if that's not possible, then we'll need to leave the simulator out. > I diff gdb-6.5 gdb-6.5-score in the top-level and the result is the > following. > Thanks for checking my patch and i hope to hear your advice on > score-tdep.c. You need to run 'diff -ruN', so it shows the contents of newly added files. I'll look at the score-tdep.[ch] files from your post yesterday. It looks as if the ROUND_UP macro is not used. In score_analyze_pdr_section, you probably want to use the following functions declared in objfiles.h, instead of the deprecated_obj_private pointer: /* Keep a registry of per-objfile data-pointers required by other GDB modules. */ extern const struct objfile_data *register_objfile_data (void); extern void clear_objfile_data (struct objfile *objfile); extern void set_objfile_data (struct objfile *objfile, const struct objfile_data *data, void *value); extern void *objfile_data (struct objfile *objfile, const struct objfile_data *data); I see that you don't use any other deprecated features, which is good. Do you need to define the read_pc and write_pc functions? If you leave them out, regcache.c's read_pc_pid and write_pc_pid should fall back to default functions which will do the ptid-swapping for you, making score_read_unsigned_register_pid, score_read_pc, and score_write_pc unnecessary 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. 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. 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.