From: Jeff D. <jd...@ad...> - 2007-01-01 20:23:21
|
I answered this, at some length, the first time you asked. On Thu, Dec 28, 2006 at 03:53:17PM +0100, Nicholas Mc Guire wrote: > On the web (user-mode-linux.sourceforge.net/debugging-skas.html), it shows > a sample session when debugging in SKAS mode - but this sample looks quite > different from what I was able to reproduce: > > in my case after sending the SIGINT to the UML process I get the > the following backtrace: > > Program received signal SIGINT, Interrupt. > 0xa014cb3a in nanosleep () at swab.h:134 > 134 { > (gdb) bt > #0 0xa014cb3a in nanosleep () at swab.h:134 > #1 0xa0010856 in idle_sleep (secs=-4) at arch/um/kernel/time.c:157 > #2 0xa000e245 in default_idle () at arch/um/kernel/process_kern.c:204 > #3 0xa0017129 in init_idle_skas () at arch/um/kernel/skas/process_kern.c:157 > #4 0xa000e260 in cpu_idle () at arch/um/kernel/process_kern.c:210 > #5 0xa000c135 in rest_init () at init/main.c:407 > #6 0xa0001502 in start_kernel () at init/main.c:548 > #7 0xa0017157 in start_kernel_proc (unused=0x0) > at arch/um/kernel/skas/process_kern.c:174 > #8 0xa00222a6 in run_kernel_thread (fn=0xa001712d <start_kernel_proc>, > arg=0x0, jmp_ptr=0x0) at arch/um/os-Linux/process.c:216 > #9 0xa0016eba in new_thread_handler (sig=10) at thread_info.h:47 > #10 <signal handler called> > #11 0xa0140531 in kill () at swab.h:134 > #12 0xbffff498 in ?? () > #13 0xa014028c in siglongjmp () at swab.h:134 > #14 0x00000000 in ?? () <---------- This is wrong ! > #15 0xa2800000 in ?? () > #16 0x00000001 in ?? () <---------- And this must also ! > #17 0xbffff4bc in ?? () > #18 0xa0016c5b in start_idle_thread (stack=Cannot access memory at address 0x9 > ) > at arch/um/kernel/skas/process.c:514 > Previous frame inner to this frame (corrupt stack?) > ^^^^^^^^^^^^^^^^^^^^^^ > ???????????????????? Everything above start_kernel in the backtrace is going to depend on things inside libc and the mechanics of how UML initializes stacks. I think the garbage is due to how UML creates stacks, and doesn't matter since control will never return that far. > My problem is that it seems I never get a glimps into the user-space > process but am "stuck" in the kernel. So I wonder if this is a pricipal > missunderstanding on my side that in the 2.6.15.5 (which Im playing with > currently) one can actually debug into the user-space task of UML (i.e. > init) ? My normal answer would be to run gdb inside UML. If you specifically want to gdb init, that's a special case. In skas mode, there is no connection between kernel stacks and userspace stacks, so you don't see the userspace stack in gdb. It wouldn't have symbols anyway, since gdb doesn't have the init debug symbols available. Jeff -- Work email - jdike at linux dot intel dot com |