Re: [Xen-devel] [PATCH] cdb: split cdb into arch independet/dependet part

[Hollis Blanchard <hollisb@xxxxxxxxxx>]

On Jan 10, 2006, at 1:31 AM, Isaku Yamahata wrote:
> split cdb into arch independent/dependet part.
What does "cdb" mean? Perhaps this is a good opportunity to rename the  
file to something like "gdbstub". Within function names, I am ok with  
"xendbg", but would again prefer "gdb".
I've done something similar for the PowerPC port (see  
http://xenbits.xensource.com/ext/xenppc-unstable.hg?cmd=file; 
filenode=e5b74ffbc35667adbe0fc2cf263bdae46d90e3ed;file=xen/common/ 
gdbstub.c). I don't claim that code is ideal, but it's working enough  
to let me focus on other things. I have a few requests for your  
arch-neutral code...
> +int
> +__trap_to_cdb(struct cpu_user_regs *regs)
Please have this take an extra argument. We can make it an opaque  
"cookie" if necessary. On PowerPC, we have more than one exception  
handler wired up to drop into GDB. The same thing is probably useful on  
other architectures as well, e.g. drop into GDB if somebody branches to  
0 in the hypervisor. This extra argument indicates the source of the  
exception, and is translated by an arch-specific hook into a signal  
number. This allows us to provide signals like SIGSEGV to indicate bad  
memory references.
Please provide arch-specific entry() and exit() hooks. On PowerPC, we  
save and restore the CPU timers in these.
int __trap_to_cdb(struct cpu_user_regs *regs, ulong cookie)
{
        arch_xendbg_entry(regs);
        signal = arch_xendbg_signal(regs, cookie);
        ...
        arch_xendbg_exit(regs);
}

I see that some commands, such as 's', 'G', and 'M' are unimplemented.  
Instead of rejecting them in the arch-neutral section, please have that  
done in the arch-specific section. For example, we have implemented all  
of those commands in PPC code.
> +                       retry = xendbg_arch_handle_register_get_command(addr, 
> regs, ctx);
I hope we can name these something shorter...

> +__initcall(initialize_xendbg);
I believe this should be an explicit call from architecture code.  
initcall is far too late for some early debugging, and only the  
architecture code knows when this call can be made.
--
Hollis Blanchard
IBM Linux Technology Center


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel