Re: [uml-devel] 2.4.22-[67] problems

[Matt Z. <md...@de...>]

On Sun, Dec 28, 2003 at 01:33:17AM -0800, Matt Zimmerman wrote:

> On Sat, Dec 20, 2003 at 05:06:56PM -0800, Matt Zimmerman wrote:
> 
> > On Sat, Dec 20, 2003 at 04:52:57PM -0800, Matt Zimmerman wrote:
> > 
> > > sh-2.05a# apt-get source -b hello
> > > apt-get: error while loading shared libraries: /lib/libm.so.6: cannot read
> > > file data: Error 38
> > > sh-2.05a# 
> > > sh-2.05a# apt-get source -b hello
> > > Reading Package Lists... Done
> > > Building Dependency Tree... Done
> > > 
> > > And of course, I haven't been able to get this to happen in the debugger
> > > (yet).
> > 
> > Well, with enough attempts, I'm able to get it to happen in gdb.  However, I
> > can't get it down to a single syscall, and can't do it reliably.  I tried
> > setting a breakpoint at the point in syscall_kern.c where it can return
> > -ENOSYS, but it never hits it.
> 
> It looks like in the case where it breaks, the system call number is 0, so
> it is passing the test in execute_syscall_skas, and instead invoking
> sys_ni_syscall.  Here is the regs struct in one instance:
> 
> $16 = {regs = {tt = {syscall = 2, sc = 0xbfffd68c}, skas = {regs = {2, 
>         3221214860, 14, 14, 3221214860, 3221214492, 4294967258, 43, 43, 0, 0, 
>         4, 1074631684, 35, 2097815, 3221214444, 43}, fp = {
>         0 <repeats 27 times>}, xfp = {2098047, 0 <repeats 31 times>, 
>         4294967295, 2734743551, 16401, 0, 0, 3413842944, 16404, 
>         0 <repeats 88 times>, 2726428672}, fault_addr = 0, fault_type = 1, 
>       trap_type = 0, syscall = 0, is_user = 1}}}
> 
> The process isn't invoking syscall 0 (in this case it was actually __NR_select
> (82)).  syscall matches ORIG_EAX, though, so I guess something is going wrong
> earlier, maybe in move_registers?

This is making less and less sense.  handle_trap has this code:

	syscall_nr = PT_SYSCALL_NR(regs->skas.regs);
	UPT_SYSCALL_NR(regs) = syscall_nr;
	if(syscall_nr < 1){
		relay_signal(SIGTRAP, regs);
		return;
	}

As I understand it, PT_SYSCALL_NR refers to ORIG_EAX, and UPT_SYSCALL_NR
refers to skas.syscall.  i.e., syscall=0 can't happen.  So either things are
not as they seem, or something is happening to regs between here and
execute_syscall_skas.  Maybe there is some disconnect between uml_pt_regs
and pt_regs?  I can't think how, though.  the structs are identical in
asm/ptrace.h.  In fact, the only differences are these:

--- ptrace.h-2.4        2003-12-28 01:44:17.000000000 -0800
+++ ptrace.h-2.6        2003-12-28 01:44:20.000000000 -0800
@@ -49,15 +49,14 @@
 #define PTRACE_GETFPXREGS         18
 #define PTRACE_SETFPXREGS         19
 
-#define PTRACE_SETOPTIONS         21
+#define PTRACE_OLDSETOPTIONS         21
 
-/* options set using PTRACE_SETOPTIONS */
-#define PTRACE_O_TRACESYSGOOD     0x00000001
+#define PTRACE_GET_THREAD_AREA    25
+#define PTRACE_SET_THREAD_AREA    26
 
 #ifdef __KERNEL__
 #define user_mode(regs) ((VM_MASK & (regs)->eflags) || (3 & (regs)->xcs))
 #define instruction_pointer(regs) ((regs)->eip)
-extern void show_regs(struct pt_regs *);
 #endif
 
 #endif


-- 
 - mdz