From owner-freebsd-current@FreeBSD.ORG Mon Jan 5 13:46:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54B1916A4CE; Mon, 5 Jan 2004 13:46:32 -0800 (PST) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 0037543D46; Mon, 5 Jan 2004 13:46:29 -0800 (PST) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 5 Jan 2004 21:46:29 +0000 (GMT) To: Don Lewis In-Reply-To: Your message of "Mon, 05 Jan 2004 11:27:30 PST." <200401051927.i05JRU7E011991@gw.catspoiler.org> Date: Mon, 05 Jan 2004 21:46:26 +0000 From: Ian Dowse Message-ID: <200401052146.aa91449@salmon.maths.tcd.ie> X-Mailman-Approved-At: Tue, 06 Jan 2004 05:22:19 -0800 cc: iedowse@maths.tcd.ie cc: shoesoft@gmx.net cc: current@FreeBSD.org Subject: gdb stack frames (was Re: page fault panic tracked down...) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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, 05 Jan 2004 21:46:32 -0000 In message <200401051927.i05JRU7E011991@gw.catspoiler.org>, Don Lewis writes: >As I've mentioned before, it appears that gdb has problems decoding >stack frames around a trap and I've seen a lot of "can't happen" things >in the stack frames leading up to the trap. FYI, my most recent attempt to debug this found a few interesting things. It seems that in a function where an argument becomes a variable stored in a register, the debugging information is supposed to include details about both where the argument is on the stack and also which register is used. The gdb code apparently prefers to use the stack version since it is less likely to be clobbered, but in the cases I looked at, there appeared only to be a register specification available. So possibly the real problem is at the compiler stage... In some examples I saw, the stack version of the argument was correct, which explains why ddb gets it right, but I couldn't find the right value in any registers, including those saved by the trap (though I didn't look very hard). Maybe one of the gcc debug-related options improves things? Of course this doesn't explain why gdb mostly works on userland programs, so it could just be that I didn't try hard enough to find the right registers. Certainly as-is, gdb does not know how to retrieve all the saved registers from a kernel trap frame itself. Ian