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
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
+__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
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,
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.
IBM Linux Technology Center
Xen-devel mailing list