This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] cdb: split cdb into arch independet/dependet part
From: Hollis Blanchard <hollisb@xxxxxxxxxx>
Date: Tue, 10 Jan 2006 08:32:19 -0600
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 10 Jan 2006 14:38:33 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20060110073119.GG9291@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20060110073119.GG9291@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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