Re: [uml-user] UML debugging question

[Nicholas Mc G. <der...@ho...>]

>>
>> 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