From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2653 invoked by alias); 30 Jan 2005 04:54:16 -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 2341 invoked from network); 30 Jan 2005 04:54:04 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 30 Jan 2005 04:54:04 -0000 Received: from drow by nevyn.them.org with local (Exim 4.43 #1 (Debian)) id 1Cv75z-0006lN-FB; Sat, 29 Jan 2005 23:53:59 -0500 Date: Sun, 30 Jan 2005 04:54: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: <20050130045359.GC25185@nevyn.them.org> Mail-Followup-To: Orjan Friberg , gdb-patches@sources.redhat.com References: <41E7969F.3010009@axis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41E7969F.3010009@axis.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2005-01/txt/msg00303.txt.bz2 On Fri, Jan 14, 2005 at 10:53:35AM +0100, Orjan Friberg wrote: > As promised, here is part 2 which contains the actual gdbserver code for > CRIS/CRISv32. > > Ok to commit? > > > 2005-01-15 Orjan Friberg > > * linux-cris-low.c: New file with support for CRIS and CRISv32 > targets. > * Makefile.in (SFILES): Add linux-cris-low.c. > (clean): Add reg-cris-c and reg-crisv32.c. > Add linux-cris-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. A couple of comments: - cris and crisv32 appear to have, from point of view of gdbserver, not much more in common than cris and mips. How about having linux-crisv32-low.c instead? There can be additional file for common code if it becomes necessary in the future. > /* We only place breakpoints in empty marker functions, and thread locking > is outside of the function. So rather than importing software > single-step, > we can just run until exit. */ > static CORE_ADDR > cris_reinsert_addr () > { > unsigned long pc; > collect_register_by_name ("srp", &pc); > return pc; > } I gather that you don't have PTRACE_SINGLESTEP on cris; not even on crisv32? (Ew. In fact, PTRACE_SINGLESTEP on cris will act as PTRACE_CONT in the kernel sources I'm looking at. That's nasty!) > > #ifdef __arch_v32 > void > cris_write_data_breakpoint (int bp, unsigned long start, unsigned long end) > { > switch (bp) > { > case 0: > supply_register_by_name("s3", &start); > supply_register_by_name("s4", &end); > break; What to do about the threaded case? GDB is having so much trouble getting it right that I'd like to make sure gdbserver does from the start. I guess this can be handled completely in the linux-low wrapper functions by switching the current thread and setting watchpoints for each. I think that is correct for all Linux targets using hardware watchpoints, because of the nature of Linux threading. -- Daniel Jacobowitz