On Monday 04 April 2005 13:55, marco ghidinelli wrote: > hello, > > i'm trying to debug a kernel with the skas patches, but it doesn't work: What you see below is very strange, never seen yet by me and not reproducible (it works ok for me, I just retested). > the uml-kernel is a vanilla 2.6.11.6. Ok. I've tested with 2.6.11 vanilla or -bs1 but that shouldn't make a difference. > the host kernel is a vanilla 2.6.11.6 with the -skas3-v8-rc5 patch. Hmm, that's ok. I'm currently testing with -V9-pre1 the below so I wouldn't notice any bugs in -V8-rc5 (which is the same as -V8), but there was no change possibly related to this.
> $ gdb linux > GNU gdb 6.3-debian I use gdb 6.2.1 on Gentoo, if that makes any difference (it shouldn't, except in case of GDB bugs, which have existed; nothing similar that I know - i.e. almost surely nothing similar ever reported in the last year. However I've not a lot of ideas). > (gdb) r > Starting program: /home/marcogh/linux-uml/linux > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0xa0010003 in _start () at proc_fs.h:159 > 159 res->data=data; > > (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) c > Continuing. > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0xa0010005 in _start () at proc_fs.h:159 > 159 res->data=data; > (gdb) > > ..... a lot of SIGTRAP here.... This is strange. > ..... until i wrote: > > (gdb) handle SIGTRAP nopass nostop noprint > SIGTRAP is used by the debugger. > Are you sure you want to change it? (y or n) y Since of this message, it is obvious what follows. What is strange is the tons of SIGTRAP above. I've even straced a UML executable and I couldn't find any SIGTRAP, except for one "sigaction" call and in the result of one "waitpid". > (it's in a loop in kernel/panic.c:115) > other random informations: Can you provide the full .config? I've even tried running in TT mode and still, I don't get your problem. I cannot understand what could be happening. > # > # Kernel hacking > # > CONFIG_DEBUG_KERNEL=y > # CONFIG_SCHEDSTATS is not set > CONFIG_DEBUG_SLAB=y > CONFIG_DEBUG_SPINLOCK=y > # CONFIG_DEBUG_SPINLOCK_SLEEP is not set > CONFIG_DEBUG_KOBJECT=y > CONFIG_DEBUG_INFO=y > # CONFIG_DEBUG_FS is not set > CONFIG_FRAME_POINTER=y > CONFIG_PT_PROXY=y Maybe you could try disabling this, and saying if it makes a difference. It's the only piece of code which could hide such a bug, but still this code shouldn't be running since it's for TT mode only. > # CONFIG_GPROF is not set > # CONFIG_GCOV is not set -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
