From owner-freebsd-hackers Tue Oct 8 8:58:17 2002 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 EA27637B401 for ; Tue, 8 Oct 2002 08:58:15 -0700 (PDT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 57E7E43E6A for ; Tue, 8 Oct 2002 08:58:14 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 8 Oct 2002 16:58:12 +0100 (BST) To: Andrew Gallatin Cc: hackers@freebsd.org Subject: Re: gdb support for kernel modules In-Reply-To: Your message of "Tue, 08 Oct 2002 09:37:22 EDT." <15778.57234.386016.42431@grasshopper.cs.duke.edu> Date: Tue, 08 Oct 2002 16:58:12 +0100 From: Ian Dowse Message-ID: <200210081658.aa35776@salmon.maths.tcd.ie> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <15778.57234.386016.42431@grasshopper.cs.duke.edu>, Andrew Gallatin writes: >gdbmods does an ugly thing which is incredibly useful. It assumes >that the modules you want to debug are sitting in your kernel build >pool. So what it does is extract the build directory from the kernel >(using strings), and runs a find rooted there for the module in >question. But its a shell script, so it can get away with stuff like >that ;) Yes, I intend to attempt the same thing by extracting the path from version[] and using similar logic. It can probably use a list of likely locations and pick the first one where the module actually exists. GDB already has the `solib-absolute-prefix' and `solib-search-path' variables, but they are of limited use for kernel modules as the paths and module names you want for debugging are usually different to those that were actually loaded. >Perhaps we could embed the build directory somewhere the elf headers >of each kernel module (including the kernel) so that kgdb could find >the corresponding build file with symbols. Then your (very cool) >solib-fbsd-kld.c could easily find the kernel and modules which match >the kernel you're debugging.. True, even having the path as a variable inside the module should be sufficient I think. The other clever suggestion that was made to me was to maintain the standard r_debug* symbols in the kernel so that a virtually unmodified gdb could extract information about the loaded modules. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message