[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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...

+__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)
        signal = arch_xendbg_signal(regs, cookie);

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...


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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.