From owner-freebsd-current@FreeBSD.ORG Mon Feb 23 17:57:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B6871065698 for ; Mon, 23 Feb 2009 17:57:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 287378FC2C for ; Mon, 23 Feb 2009 17:57:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id A636D46B0C; Mon, 23 Feb 2009 12:57:37 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n1NHvVSp017192; Mon, 23 Feb 2009 12:57:31 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Scott Long Date: Mon, 23 Feb 2009 12:57:27 -0500 User-Agent: KMail/1.9.7 References: <5D267A3F22FD854F8F48B3D2B5238193394588D54D@IRVEXCHCCR01.corp.ad.broadcom.com> <200902231119.54925.jhb@freebsd.org> <49A2D86F.1000509@samsco.org> In-Reply-To: <49A2D86F.1000509@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902231257.28060.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 23 Feb 2009 12:57:31 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/9032/Mon Feb 23 10:05:24 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: David Christensen , freebsd-current@freebsd.org Subject: Re: Hopefully Simple Question on Debugging Kernel Modules X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 17:57:38 -0000 On Monday 23 February 2009 12:10:07 pm Scott Long wrote: > John Baldwin wrote: > > On Friday 20 February 2009 6:40:56 pm David Christensen wrote: > >> I'm sure this is a simple question but the answer is alluding my Google > >> search capabilities. My driver is being loaded as a kernel module and > >> is failing with the following error: > >> > >> Fatal trap 12: page fault while in kernel mode > >> cpuid = 0; apic id = 00 > >> fault virtual address = 0xfffffffe40abe9dc > >> fault code = supervisor write data, page not present > >> instruction pointer = 0x8:0xffffffff920b638f > >> stack pointer = 0x10:0xffffffff9212bb10 > >> frame pointer = 0x10:0xffffffff9212bbb0 > >> code segment = base 0x0, limit 0xfffff, type 0x1b > >> = DPL 0, pres 1, long 1, def32 0, gran 1 > >> processor eflags = interrupt enabled, resume, IOPL = 0 > >> current process = 12 (irq268: bce0) > >> [thread pid 12 tid 100166 ] > >> Stopped at bce_intr+0x8df: addl $0x1,0x2c854(%r12,%rax,4) > >> db> > >> > >> I simply need to find the offending source line in my driver. Not sure > >> how I've managed to get the driver running at all without this but it's > >> time to do things the right way. I have KDB/DDB/GDB built into my > >> -CURRENT kernel already. It'd be great to find the source line while in > >> the kernel debugger but I'm also fine with rebooting the system to > >> identify the line number. > > > > Just use gdb on bce.ko (built with debug symbols): > > > > gdb /path/to/if_bce.ko > > (gdb) l *bce_intr+0x8df > > > > If you get a crashdump you can run kgdb on it and just walk up to the relevant > > stack frame and use 'l' there to get a listing. > > > > One thing that I've never figured out is how debugging symbols are > handled in module builds these days. If I go to /sys/modules/bce and > do 'make', it generates a .ko and explicitly strips it. I wind up > having to re-run the link command by hand so I get symbols. What is > the correct way to do this? Note that I'm not interested in answers > that involve "go to /usr/src and run make buildkernel" =-) make DEBUG_FLAGS=-g is what I use. The same thing works for userland tools and the kernel (usually we put 'makeoptions DEBUG_FLAGS=-g' in a kernel config so it is "automatic" for kernels though). -- John Baldwin