From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14754 invoked by alias); 24 Feb 2005 20:49:17 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 14714 invoked from network); 24 Feb 2005 20:49:12 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 24 Feb 2005 20:49:12 -0000 Received: from drow by nevyn.them.org with local (Exim 4.44 #1 (Debian)) id 1D4Pv0-0003Vz-25; Thu, 24 Feb 2005 15:49:06 -0500 Date: Thu, 24 Feb 2005 20:57:00 -0000 From: Daniel Jacobowitz To: Orjan Friberg Cc: gdb-patches@sources.redhat.com Subject: Re: [gdbserver/rfa] CRIS/CRISv32 gdbserver support (part 2) Message-ID: <20050224204906.GC11751@nevyn.them.org> Mail-Followup-To: Orjan Friberg , gdb-patches@sources.redhat.com References: <41E7969F.3010009@axis.com> <20050130045359.GC25185@nevyn.them.org> <41FF9274.7030700@axis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41FF9274.7030700@axis.com> User-Agent: Mutt/1.5.6+20040907i X-SW-Source: 2005-02/txt/msg00253.txt.bz2 On Tue, Feb 01, 2005 at 03:30:12PM +0100, Orjan Friberg wrote: > For CRISv32, there might be an additional problem lurking in the shadows: > we treat the watchpoint registers as global (i.e., only one process at a > time can use them, and thus they are not saved/restored on context switches > etc). As I wrote in my other message, that's a pretty serious bug. > Anyway, is this something you want resolved before I commit the > CRIS/CRISv32 support? (Here's an updated ChangeLog entry and updated > patches if not.) Let's go ahead. The patch is mostly OK, but I have a last question or two... > 2005-02-01 Orjan Friberg > > * linux-cris-low.c: New file with support for CRIS. > * linux-crisv32-low.c: Ditto for CRISv32. > * Makefile.in (SFILES): Add linux-cris-low.c, linux-crisv32-low.c. > (clean): Add reg-cris.c and reg-crisv32.c. > Add linux-cris-low.o, linux-crisv32-low.o, reg-cris.o, reg-cris.c, > reg-crisv32.o, and reg-crisv32.c to make rules. > * configure.srv: Add cris-*-linux* and crisv32-*-linux* to list of > recognized targets. > > -- > Orjan Friberg > Axis Communications > > static const unsigned long cris_breakpoint = 0xe938; > #define cris_breakpoint_len 2 > > static int > cris_breakpoint_at (CORE_ADDR where) > { > unsigned long insn; > > (*the_target->read_memory) (where, (char *) &insn, 4); > if (insn == cris_breakpoint) > return 1; > > /* If necessary, recognize more trap instructions here. GDB only uses the > one. */ > return 0; > } If the breakpoint length is two, why are you reading and testing four bytes? > void > cris_write_data_breakpoint (int bp, unsigned long start, unsigned long end) Please make new functions static where possible, which is pretty much everywhere. > int > cris_stopped_by_watchpoint () And use prototypes - that's not a prototype, because of the missing (void). > struct regset_info target_regsets[] = { > { PTRACE_GETREGS, PTRACE_SETREGS, sizeof (elf_gregset_t), > GENERAL_REGS, cris_fill_gregset, cris_store_gregset }, > { 0, 0, -1, -1, NULL, NULL } > }; Does the regset cover everything that that regmap covers, including debug registers? The current support for both PEEKUSER and regsets is purely for compatibility; it doesn't support getting some registers from one and some from another. So if all crisv32 kernels support PTRACE_GETREGS, your regmap is never getting used. I have code around here somewhere to support targets that need both, but it's gross. -- Daniel Jacobowitz CodeSourcery, LLC