Date: Sun, 11 Jan 2004 13:45:39 +0200 From: Tom Alsberg <alsbergt@cs.huji.ac.il> To: FreeBSD Hackers List <freebsd-hackers@freebsd.org> Subject: Remote GDB online and kernel functions Message-ID: <20040111114539.GA53691@cs.huji.ac.il>
next in thread | raw e-mail | index | archive | help
Hi there. I sent the following question to the list a while ago, and got no answer yet. The problem looks weird to me, but I have the feeling that I'm missing something very simple (I did RTFM, though) - so if anyone can provide any guidance - cannot be that complicated of a question... I didn't look much into the sources of the kernel GDB (db_interface.c, etc. etc.), but from what I saw I wasn't sure what's going on. I'm asking again because it would really ease one of the things I have on my "to do" queue (which I haven't touched recently because of that problem): I'm fooling around a bit with kernel hacking recently, and got a bit to work with online kernel debugging with GDB (over a serial port). I built the kernel (FreeBSD-4.9) with DDB and -g compile option, and set the flag on sio0, as described in section 10.6 of the FreeBSD Developer's Handbook at: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-gdb.html Using gdb -k I can open the kernel image, and doing 'target remote /dev/cuaa0' I can attach to the debugged host (having switched to gdb mode from DDB on it, and entered 's' to generate a trap). Trying to figure out some stuff I can do with it, I noticed that for some reason I cannot call any kernel functions from kgdb... When entering, e.g. the command: (kgdb) call print_uptime() gdb points it caught of a SIGSEGV, which actually is a panic on the host - I see a fatal trap 12 (page fault while in kernel mode), with fault code 'supervisor read, page not present'... Am I in some special context when inside the kernel debugger, from which other kernel functions cannot be called? (no access to their page?) What needs to be done to setup the paging and memory protection to be able to do so? The even more weird thing yet is that from the information in the panic, during the panic the instruction pointer, frame pointer (but not the stack pointer), and panic virtual address are zero: fault virtual address = 0x0 instruction pointer = 0x8:0x0 frame pointer = 0x10:0x0 I thought maybe there is some zero at the time of return from the function when ret is executed (so the CPU tries to jump to address 0), but having put some breakpoints inside the function, I see that the panic is even before the first instruction of it executes... I found very little documentation on kernel debugging, except on how to get into DDB and use it a bit, how to debug offline with gdb with crash dumps, and how to start a remote online GDB session through the serial port on a running kernel... In the Developer's Handbook there are examples on usage of DDB online, and GDB offline on a crash dump, but no examples of online remote GDB usage. I am not sure how exactly the contexts of the kernel should affect debugging which (as far as I understand) is done completely within the kernel, and how the kernel debugger/GDB interferes... I'll try to learn more and perhaps understand it... But can someone provide some ideas as to what is the cause of the problem, what is exactly happening and why, and how to overcome it? Thanks, any help appreciated, -- Tom -- Tom Alsberg - hacker (being the best description fitting this space) Web page: http://www.cs.huji.ac.il/~alsbergt/ DISCLAIMER: The above message does not even necessarily represent what my fingers have typed on the keyboard, save anything further.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040111114539.GA53691>