On Thu, 23 Dec 1999, Brian Hall wrote:
|>OK, I've got the following code in __dump_execute:
|>
|>__dump_execute(struct file *dump_file, char *panic_str,
|> struct pt_regs *regs, int dump_level, int dump_compress_pages)
|>{
|>dump_here:
|>
|>( some code skipped here)
|>
|> /* For Alpha, save the Program Counter and Stack Pointer */
|> dump_header.dh_esp = __asm__("$30"); /* get stack pointer */
|> dump_header.dh_eip = &&dump_here; /* get Program Counter */
|>
|>Sound OK?
That sounds just fine. :)
|>I removed the cmd directory temporarily from the top level Makefile so I could
|>do a test build (lots of work todo there!). Had to fix a type in sd.c, but the
|>compile died completely when it reached arch/alpha/kernel/vmdump.c, apparently
|>because it couldn't see vmdump.h. Huh? File does exist as requested in
|>include/linux; adding an include line with the explicit path to it didn't
help.
Do you have:
#ifndef CONFIG_VMDUMP
#define CONFIG_VMDUMP
#include <linux/vmdump.h>
#endif
at the top of the file? This might be needed if you're compiling the
new vmdump.o, but you don't have CONFIG_VMDUMP set. Just a thought.
If that file gets built, it's because CONFIG_VMDUMP is in the object.
Look at arch/i386/kernel/Makefile for an example:
ifdef CONFIG_VMDUMP
O_OBJS += vmdump.o
endif
|>Any idea why this fails to see the include? /usr/src/linux is actually
|>symlinked to a mounted NFS share that holds the kernel source; doesn't seem
|>like that would be the problem since the rest of the kernel was building fine.
|>/usr/include/linux points to ../src/linux/include/linux/.
Let me know what happens ...
--Matt
|>On 21-Dec-1999 Matt Robinson wrote:
|>> On Thu, 23 Dec 1999, Brian Hall wrote:
|>>|>Well, it's not clear to me how to get the PC and RA of interest off the
|>>|>stack
|>>|>when we are in the vmdump functions. We could retreive the RA from register
|>>|>26
|>>|>in the panic() function itself, and pass that to the dump_execute function.
|>>|>Then the dump code could at least tell where panic was called from. Is this
|>>|>sufficient, or at least a start?
|>>
|>> In the __dump_execute() function, just save the PC into the right
|>> registers, and that'll be enough. You don't have to fill the pt_regs
|>> structure.
|>>
|>> The big keys are the stack pointer and the PC for that process within
|>> the __dump_execute() function. Save the stack pointer into
|>> dump_header.dh_esp, and the PC into dump_header.dh_eip. That's all
|>> 'lcrash' should need in order to figure out the stack trace of the
|>> failing process (for now). Having the RA is nice, but not entirely
|>> necessary.
|>>
|>> I should have named dh_esp and dh_eip into something like dh_sp and
|>> dh_pc, for simplicity's sake. Next revision ...
|>>
|>> --Matt
|>>
|>>|>On 18-Dec-1999 Brian Hall wrote:
|>>|>> Okay, after some research, I think I figured out how to get at the needed
|>>|>> Alpha registers:
|>>|>>
|>>|>> register unsigned long fptr __asm__("$15"); /* get frame pointer? */
|>>|>> register unsigned long sptr __asm__("$30"); /* get stack pointer? */
|>>|>>
|>>|>> Now, my understanding of the problem is that I need to go back two frames
|>>|>> on
|>>|>> the stack to get the PC of interest, and three for the RA of interest.
How
|>>|>> do
|>>|>> I
|>>|>> do this? I haven't had much luck yet trying to figure out how to navigate
|>>|>> the
|>>|>> kernel stack. I see the pt_regs structure, but I'm not exactly sure how
to
|>>|>> figure the frame size, since that can vary with each frame.
|>>|>>
|>>|>> On 13-Dec-1999 Matt Robinson wrote:
|>>|>>> The problem is from panic(), you don't have the registers, so you
|>>|>>> need to grab them. That way the 'lcrash' code has a point to start
|>>|>>> with as far as the failing process is concerned. Hence the "if (regs)"
|>>|>>> stuff.
|>>|>
|>>|>--
|>>|>Brian Hall <brianw.hall@xxxxxxxxxx>
|>>|>Linux Consultant
|>
|>
|>--
|>Brian Hall <brianw.hall@xxxxxxxxxx>
|>Linux Consultant
|>
|