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