Date: Mon, 05 Jan 2004 21:46:26 +0000 From: Ian Dowse <iedowse@maths.tcd.ie> To: Don Lewis <truckman@FreeBSD.org> Cc: current@FreeBSD.org Subject: gdb stack frames (was Re: page fault panic tracked down...) Message-ID: <200401052146.aa91449@salmon.maths.tcd.ie> In-Reply-To: Your message of "Mon, 05 Jan 2004 11:27:30 PST." <200401051927.i05JRU7E011991@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401052146.aa91449>