I see.
The first number (which I always assumed was just
the numeric equivalent of the function+offset shown in the next column)
is the frame pointer for the associated stack frame.
Presumably, the first line findstack prints is a typo: it calls the value
"stack pointer"
I think it is reall
On Mon, Jun 15, 2009 at 02:35:10PM -0700, Steve Gonczi wrote:
> > My experience with the gdb protocol has been very
> > negative; it's
> > very poorly designed, and prone to breakage.
>
> And, with a little luck, nobody from the GNU camp is reading this list :-)
I think my experience is all wel
> My experience with the gdb protocol has been very
> negative; it's
> very poorly designed, and prone to breakage.
And, with a little luck, nobody from the GNU camp is reading this list :-)
> While some kind of kmdb(1)-over-ethernet might be
> very cool...
Yes.. given that trying to get a KMD
On Mon, Jun 15, 2009 at 12:10:12PM -0700, Steve Gonczi wrote:
> Absolutely no disrespect to mdb, I love the thing for kernel/assembler
> debugging.
>
> However, stepping through source code, walking the stack frames,
> seeing local variables effortlessly is still a significant plus.
>
> What I woul
Hi Jonathan,
Thanks for providing us with a SUN developer's perspective, and for the new
info on config tweaks.
I have gained a tiny bit more insight on this:
The debug (-g) option is already set in all the compiles, given that the
requisite bldenv is set up as debug.
It is currently unclear
On Fri, Jun 12, 2009 at 03:04:55PM -0700, Steve Gonczi wrote:
> I did the full nightly, then edited the Makefile.master debug setting so it
> generates dwarf debug info. Killed the CTF* utilities as outlined
> previously in this thread.
> Recompiled libzpool and libzfs from their usr/src/li
