Re: [gdbserver/rfa] CRIS/CRISv32 gdbserver support (part 2)

[Daniel Jacobowitz <drow@false.org>]

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