I have a few crash dumps I'm trying to analyze and I want to trace some user threads down to their user mode callstacks. It has been my understanding that I can only interpret the stack raw and pick out the return addresses among the data which isn't so bad when you have symbols. In my case I'm looking at dumps running an amd64 kernel and 32-bit user code.
While in the kernel context and given a specific kthread, I print the regs structure from the lwp and get the user mode context. Then I switch mdb's context to the process of that thread and attempt to get a callstack. For a 64-bit kernel and 64-bit user code or 32-bit kernel and 32-bit user code I just do [r_(e/r)sp]-200,0t64/nap. But for 64-bit kernel code and 32-bit user code, it interprets the stack as a 64-bit one, reading 8 bytes at a time instead of 4 and of course this means no symbols will match since the stack is being interpreted incorrectly. I thought setting the disassembler to ia32 would have made things happy but it doesn't. How can I make that stack print correctly using 4bytes instead of 8 per entry and have automatic symbol lookup? Is there some easier way to get the user mode stack? (It still would be nice to know how to do the above still in case I have some random pointer that I want to treat as a stack). I'm tired of deciphering the call stack by hand/guess/check/luck when there are no happy frame pointers to keep things sane and /nap is the easiest way I know of if only it would work in this one case. This message posted from opensolaris.org