From: Nicholas Mc G. <der...@ho...> - 2006-12-28 15:49:11
|
Hi ! I've been working my way through debuging with UML both with 2.4.X and 2.6.X. In the later case I can't reproduce the results from the webpage: Kernel 2.6.15.5 on host (skas3-v9-pre8 patch on howt) kernel 2.6.15.5 as UML Config: UML-specific options ---> [*] Tracing thread support ... [*] Separate Kernel Address Space support Kernel Hacking ---> ... [*] Compile the kernel with debug info ... [*] Compile the kernel with frame pointers ... [*] Show command line arguments on the host in TT mode [*] Enable ptrace proxy [ ] Enable gcov support [*] Enable system call debugging Also tried it with ptrace proxy off and in SKAS only mode (no TT) 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: Program received signal SIGINT, Interrupt. 0xa019a6c1 in __libc_nanosleep () (gdb) bt #0 0xa019a6c1 in __libc_nanosleep () #1 0xa00ed092 in idle_sleep (secs=10) at time.c:114 #2 0xa00e5765 in cpu_idle () at process_kern.c:210 #3 0xa000c50e in rest_init () at init/main.c:341 #4 0xa000356d in start_kernel () at init/main.c:435 #5 0xa00f38f7 in start_kernel_proc (unused=0x0) at process_kern.c:153 #6 0xa00e52a2 in run_kernel_thread (fn=0xa00f38d0 <start_kernel_proc>, arg=0x0, jmp_ptr=0xa020c554) at process.c:239 #7 0xa00f36de in new_thread_handler (sig=10) at process_kern.c:67 #8 <signal handler called> #9 0xa01891d1 in __kill () #10 0xa0188f85 in siglongjmp () at ../sysdeps/generic/longjmp.c:39 #11 0xa00f32e3 in start_idle_thread (stack=0xa020e000, switch_buf_ptr=0xa020c57c, fork_buf_ptr=0xa020c580) at process.c:275 #12 0xa00f3947 in start_uml_skas () at process_kern.c:169 #13 0xa00ee779 in linux_main (argc=8, argv=0xbffff814) at um_arch.c:376 #14 0xa000c3d2 in main (argc=8, argv=0xbffff814, envp=0xbffff838) at arch/um/main.c:143 #15 0xa0188d52 in __libc_start_main (main=0xa000c1dc <main>, argc=8, ubp_av=0xbffff814, init=0xa01c6520 <_init>, fini=0xa01c6cb0 <_fini>, rtld_fini=0, stack_end=0xbffff80c) at ../sysdeps/generic/libc-start.c:129 (gdb) 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?) ^^^^^^^^^^^^^^^^^^^^^^ ???????????????????? 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) ? The apps (busybox-1.2.2.1) is compiled with debugging (-g3) and the libs Bare not stripped - framepointer and debuging symbols are enabled in kernel hacking - SKAS patched into the host (SKAS3) and UML running SKAS / SKAS+TT (same behavior). could you give me a pointer to what Im messing up here ? Or is this jsut a missunderstanding on my side that I actually should be able to get all the way into the libc/user-space app ? If it makes sense I can post a more detailed description of the setup and how to reproduce these (bad) results. thx ! hofrat |
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 |
From: Nicholas Mc G. <der...@ho...> - 2007-01-02 08:49:10
|
>> >> 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. > I got confused from the trace on the web as that seems to go into libc but that then only was posible for linux it self not for any of the processes within linux - that was the missunderstnading. >> 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. > well loading the symbols is not the problem - I actually did try to load busybox to get the symbols but looking at the addresses it seemed obvious that the addresses them selves are wrong and thus the symbols garbage. The unavailable stack is the show stoper then I guess. thanks ! hofrat |