Sometimes the current status dump is not quite enough for debugging. One example is when the RIP somehow ends up with a weird value, e.g. the middle of allocated memory, and that code is hence not visible in the disassembled kernel.
The exit now prints a bit more information, and a hex dump of the 16 bytes starting at RIP. This little extra bit of information allowed me to figure out a strange problem I was having. Change-Id: Ic37396d48bfe8934d7943e9ac6729540468badfa Signed-off-by: Ronald G. Minnich <[email protected]> --- user/vmm/sched.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/user/vmm/sched.c b/user/vmm/sched.c index a489f6d..8bd774f 100644 --- a/user/vmm/sched.c +++ b/user/vmm/sched.c @@ -320,8 +320,18 @@ static void __ctlr_entry(void) { struct ctlr_thread *cth = (struct ctlr_thread*)current_uthread; struct virtual_machine *vm = gth_to_vm(cth->buddy); + struct vm_trapframe *vm_tf = &(cth->buddy->uthread.u_ctx.tf.vm_tf); if (!handle_vmexit(cth->buddy)) { + fprintf(stderr, "vmm: handle_vmexit returned false\n"); + fprintf(stderr, "Note: this may be in a kernel module,"); + fprintf(stderr, "not the kernel\n"); + fprintf(stderr, "RIP was %p:\n", (void *)vm_tf->tf_rip); + /* TODO: properly walk the kernel page tables to map the tf_rip + * to a physical address. For now, however, this hack is good + * enough. + */ + hexdump(stderr, (void *)(vm_tf->tf_rip&0x3fffffff), 16); showstatus(stderr, cth->buddy); exit(0); } -- 2.8.0.rc3.226.g39d4020 -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
