This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [gdbserver/rfa] CRIS/CRISv32 gdbserver support (part 2)
- From: Daniel Jacobowitz <drow at false dot org>
- To: Orjan Friberg <orjan dot friberg at axis dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Sat, 29 Jan 2005 23:53:59 -0500
- Subject: Re: [gdbserver/rfa] CRIS/CRISv32 gdbserver support (part 2)
- References: <41E7969F.3010009@axis.com>
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 <orjanf@axis.com>
>
> * 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