On Tue, Aug 14, 2007 at 09:17:02PM +0000, Alberto Pires de Oliveira Neto wrote:
> 6c4a3a48:  [<60026555>] hard_handler+0x15/0x18
> 6c4a3b08:  [<60094397>] elf_core_dump+0x1ed/0x25e

There are two problems here.

First, some process is dumping core, and you might want to figure out
what it is.

Second, UML/x86_64 doesn't react well to a process trying to dump
core.  The patch below fixes it, but is somewhat incomplete.

                                Jeff
-- 
Work email - jdike at linux dot intel dot com

Index: linux-2.6.22/arch/um/sys-x86_64/ptrace.c
===================================================================
--- linux-2.6.22.orig/arch/um/sys-x86_64/ptrace.c       2007-08-09 
14:07:41.000000000 -0400
+++ linux-2.6.22/arch/um/sys-x86_64/ptrace.c    2007-08-09 16:18:06.000000000 
-0400
@@ -158,8 +158,8 @@ int is_syscall(unsigned long addr)
 
 int dump_fpu(struct pt_regs *regs, elf_fpregset_t *fpu )
 {
-       panic("dump_fpu");
-       return(1);
+       memset(fpu, 0, sizeof(*fpu));
+       return 1;
 }
 
 int get_fpregs(unsigned long buf, struct task_struct *child)
Index: linux-2.6.22/include/asm-um/elf-x86_64.h
===================================================================
--- linux-2.6.22.orig/include/asm-um/elf-x86_64.h       2007-08-09 
14:07:41.000000000 -0400
+++ linux-2.6.22/include/asm-um/elf-x86_64.h    2007-08-09 16:18:27.000000000 
-0400
@@ -64,6 +64,35 @@ typedef struct { } elf_fpregset_t;
        PT_REGS_R15(regs) = 0; \
 } while (0)
 
+#define ELF_CORE_COPY_REGS(pr_reg, regs)               \
+       (pr_reg)[0] = (regs)->regs.gp[0];                       \
+       (pr_reg)[1] = (regs)->regs.gp[1];                       \
+       (pr_reg)[2] = (regs)->regs.gp[2];                       \
+       (pr_reg)[3] = (regs)->regs.gp[3];                       \
+       (pr_reg)[4] = (regs)->regs.gp[4];                       \
+       (pr_reg)[5] = (regs)->regs.gp[5];                       \
+       (pr_reg)[6] = (regs)->regs.gp[6];                       \
+       (pr_reg)[7] = (regs)->regs.gp[7];                       \
+       (pr_reg)[8] = (regs)->regs.gp[8];                       \
+       (pr_reg)[9] = (regs)->regs.gp[9];                       \
+       (pr_reg)[10] = (regs)->regs.gp[10];                     \
+       (pr_reg)[11] = (regs)->regs.gp[11];                     \
+       (pr_reg)[12] = (regs)->regs.gp[12];                     \
+       (pr_reg)[13] = (regs)->regs.gp[13];                     \
+       (pr_reg)[14] = (regs)->regs.gp[14];                     \
+       (pr_reg)[15] = (regs)->regs.gp[15];                     \
+       (pr_reg)[16] = (regs)->regs.gp[16];                     \
+       (pr_reg)[17] = (regs)->regs.gp[17];                     \
+       (pr_reg)[18] = (regs)->regs.gp[18];                     \
+       (pr_reg)[19] = (regs)->regs.gp[19];                     \
+       (pr_reg)[20] = (regs)->regs.gp[20];                     \
+       (pr_reg)[21] = current->thread.arch.fs;                 \
+       (pr_reg)[22] = 0;                                       \
+       (pr_reg)[23] = 0;                                       \
+       (pr_reg)[24] = 0;                                       \
+       (pr_reg)[25] = 0;                                       \
+       (pr_reg)[26] = 0;
+
 #ifdef TIF_IA32 /* XXX */
 #error XXX, indeed
         clear_thread_flag(TIF_IA32);

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
User-mode-linux-user mailing list
User-mode-linux-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user

Reply via email to