From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 30 03:41:46 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40F0816A4CF for ; Tue, 30 Dec 2003 03:41:46 -0800 (PST) Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 609A643D54 for ; Tue, 30 Dec 2003 03:41:44 -0800 (PST) (envelope-from alsbergt@cs.huji.ac.il) Received: from serin.cs.huji.ac.il ([132.65.80.149] ident=exim) by cs.huji.ac.il with esmtp id 1AbIFq-0007Fs-Et for freebsd-hackers@freebsd.org; Tue, 30 Dec 2003 13:41:42 +0200 Received: from alsbergt by serin.cs.huji.ac.il with local (Exim 4.12) id 1AbIFq-0000UM-00 for freebsd-hackers@freebsd.org; Tue, 30 Dec 2003 13:41:42 +0200 Date: Tue, 30 Dec 2003 13:41:42 +0200 From: Tom Alsberg To: FreeBSD Hackers List Message-ID: <20031230114142.GA1838@cs.huji.ac.il> Mail-Followup-To: Tom Alsberg , FreeBSD Hackers List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Face: "5"j@Y1Peoz1; ftTv>\|['ox-csmV+:_RDNdi/2lSe2x?0:HVAeVW~ajwQ7RfDlcb^18eJ; t,O,s5-aNdU/DJ2E8h1s,..4}N9$27u`pWmH|; s!zlqqVwr9R^_ji=1\3}Z6gQBYyQ]{gd5-V8s^fYf{$V2*_&S>eA|SH@Y\hOVUjd[5eah{EO@gCr.ydSpJHJIU[QsH~bC?$C@O:SzF=CaUxp80-iknM(]q(W List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2003 11:41:46 -0000 Hi there. 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.