lkcd
[Top] [All Lists]

new problem: can't see vmdump.h?

To: Matt Robinson <yakker@xxxxxxxxxxxxxxxxxxxx>
Subject: new problem: can't see vmdump.h?
From: Brian Hall <brianw.hall@xxxxxxxxxx>
Date: Thu, 23 Dec 1999 16:46:16 -0700 (MST)
Cc: comp.os.linux.alpha@xxxxxxxxxxxxx, lkcd@xxxxxxxxxxx, axp-list@xxxxxxxxxx
In-reply-to: <Pine.SGI.3.94.991221120253.366688K-100000@xxxxxxxxxxxxxxxxxxxx>
Reply-to: Brian Hall <brianw.hall@xxxxxxxxxx>
Sender: owner-lkcd@xxxxxxxxxxx
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?

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.
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/.

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

<Prev in Thread] Current Thread [Next in Thread>