On Wed, Mar 20, 2013 at 7:20 PM, Antoine Martin <anto...@nagafix.co.uk> wrote:
> On 03/21/2013 05:53 AM, Han wrote:
>> Hi Richard,
>>
>> I hit other issues after moving to a recent kernel UML (i.e. cannot
>> fully bring up the UML).  Now I am back and trying to debug UML
>> itself. However,  when I started GDB with UML,  I would hit a crash
>> like the following.
>>
>> I was wondering if I used the GDB in wrong way.  I couldn't find
>> detailed info about GDB UML kernel.  Any pointers? Note, this is host
>> GDB x86_64,  the UML kernel is built as 32-bit (SUBARCH=i386).  Is
>> that a problem?
> http://uml.devloop.org.uk/faq.html#gdb
> handle SIGSEGV pass nostop noprint

Thanks.  I tried this but still have issues:

1) compile your kernel with DEBUG_INFO and FRAME_POINTER  -   I did this.
2) tell gdb to ignore SIGSEGV: handle SIGSEGV noprint nostop pass  -
I did this.

It crashed after making some progress:

(gdb) handle SIGSEGV pass nostop noprint
Signal        Stop      Print   Pass to program Description
SIGSEGV       No        No      Yes             Segmentation fault
(gdb) handle SIGUSR1 pass nostop noprint
Signal        Stop      Print   Pass to program Description
SIGUSR1       No        No      Yes             User defined signal 1
(gdb) run mem=128M
ubda=cow1,/nobackup/hxu2/uml/Debian-Squeeze-x86-root_fs umid=debian1
Starting program: /nobackup/hxu2/uml/linux-2.6.27/linux mem=128M
ubda=cow1,/nobackup/hxu2/uml/Debian-Squeeze-x86-root_fs umid=debian1
<snip>
.....
<snip>
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Detaching after fork from child process 17290.
Kernel panic - not syncing: Attempted to kill init!

EIP: 0023:[<40014660>] CPU: 0 Not tainted ESP: 002b:ff88c194 EFLAGS: 00010282
    Not tainted
EAX: ff88c1e8 EBX: 4001bff4 ECX: ff88c39c EDX: ff88dfd6
ESI: ff88c1e8 EDI: 400198fd EBP: ff88c198 DS: 002b ES: 002b
0f85ad8c:  [<08069b53>] show_regs+0xb4/0xb9
0f85adb8:  [<08059426>] panic_exit+0x25/0x3b
0f85adcc:  [<080836d6>] notifier_call_chain+0x27/0x4c
0f85adf4:  [<08083712>] __atomic_notifier_call_chain+0x17/0x19
0f85ae04:  [<08083729>] atomic_notifier_call_chain+0x15/0x17
0f85ae20:  [<0806fea3>] panic+0x52/0xd8
0f85ae40:  [<08072873>] do_exit+0x5a/0x6aa
0f85ae7c:  [<08072f3f>] do_group_exit+0x7c/0xa3
0f85ae98:  [<0807ad11>] get_signal_to_deliver+0x295/0x2d7
0f85aebc:  [<08057e07>] do_signal+0x1d5/0x27c
0f85af7c:  [<08057292>] interrupt_end+0x31/0x35
0f85af8c:  [<0806710f>] userspace+0x344/0x353
0f85afe8:  [<08057436>] new_thread_handler+0x72/0x7e
0f85affc:  [<00000000>] 0x0


Program received signal SIGTERM, Terminated.

Should I ignore SIGTERM also ?

Thanks
Han

>
> Antoine
>
>
>
>
>>
>> host#/usr/bin/gdb ./linux
>> GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-32.el5_6.2)
>> Copyright (C) 2009 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-redhat-linux-gnu".
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/>...
>> Reading symbols from linux...(no debugging symbols found)...done.
>> (gdb) run  mem=128M ubda=cow1,Debian-Squeeze-x86-root_fs umid=debian1
>> Starting program: linux mem=128M ubda=cow1,Debian-Squeeze-x86-root_fs
>> umid=debian1
>> Locating the bottom of the address space ...
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x080662fb in page_ok (page=<value optimized out>) at
>> arch/um/os-Linux/sys-i386/task_size.c:31
>> 31                      n = *address;
>> (gdb) bt
>> #0  0x080662fb in page_ok (page=<value optimized out>) at
>> arch/um/os-Linux/sys-i386/task_size.c:31
>> #1  0x08066403 in os_get_top_address () at
>> arch/um/os-Linux/sys-i386/task_size.c:100
>> #2  0x0804a271 in linux_main (argc=4, argv=0xffff8ac4) at
>> arch/um/kernel/um_arch.c:277
>> #3  0x0804ad3d in main (argc=4, argv=0xffff8ac4, envp=0xffff8ad8) at
>> arch/um/os-Linux/main.c:150
>> (gdb)
>>
>>
>> On Fri, Mar 15, 2013 at 11:36 AM, Han <keepsim...@gmail.com> wrote:
>>> On Fri, Mar 15, 2013 at 11:11 AM, Han <keepsim...@gmail.com> wrote:
>>>> On Fri, Mar 15, 2013 at 10:50 AM, richard -rw- weinberger
>>>> <richard.weinber...@gmail.com> wrote:
>>>>> On Fri, Mar 15, 2013 at 6:01 PM, Han <keepsim...@gmail.com> wrote:
>>>>>> I started UML with "mem=128M",  the module init only kmalloc 8 bytes:
>>>>>>
>>>>>> kmalloc(size, GFP_KERNEL);
>>>>>>
>>>>>> where "size" is 8.
>>>>>
>>>>> This has to work. Just in case, please retry with a more recent kernel.
>>>>
>>>> I will retry to a more recent kernel.  On another front, I suspect
>>>> that I might be using incorrect compiling/linking for the module.
>>>> Because of certain constraints, I was modifying the build command from
>>>> existing builds of the module code.   The existing build were for x86
>>>> linux, and I modified them to use x86 UML.
>>>>
>>>> I modified the options for "gcc", and I think the compile is ok.  But
>>>> I did not modify "ld" command.   Is there anything I should do for
>>>> "ld" making sure linking was ok for the UML ?  Here is example of my
>>>> current ld:
>>>>
>>>> /usr/bin/ld -nostdlib -m elf_i386 -r -o <my_uml_module_name>
>>>> <my_c_obj1>  <my_c_obj2>
>>>>
>>>> the "ld" was successful but now I suspect it was only for the host,
>>>> not good for UML.   Note:  my host linux uses different kernel version
>>>> from the UML tree.  The host kernel version is 2.6.18.
>>>
>>> Btw,  the UML kernel Changes file states the following requirements:
>>>
>>> o  Gnu C                  3.2                     # gcc --version
>>> o  Gnu make               3.79.1                  # make --version
>>> o  binutils               2.12                    # ld -v
>>>
>>> and I am using the following versions:
>>>
>>> gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-50)
>>> GNU Make 3.80
>>> GNU ld version 2.17.50.0.6-14.el5 20061020
>>>
>>> Thanks
>>> Han
>>>
>>>>
>>>> Thanks
>>>> Han
>>>>
>>>>>
>>>>> --
>>>>> Thanks,
>>>>> //richard
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> _______________________________________________
>> User-mode-linux-user mailing list
>> User-mode-linux-user@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
>>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> User-mode-linux-user mailing list
> User-mode-linux-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
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