lkcd
[Top] [All Lists]

dump_header changes for Alpha

To: Matt Robinson <yakker@xxxxxxxxxxxxxxxxxxxx>
Subject: dump_header changes for Alpha
From: Brian Hall <brianw.hall@xxxxxxxxxx>
Date: Mon, 03 Jan 2000 14:53:43 -0700 (MST)
Cc: lkcd@xxxxxxxxxxx
In-reply-to: <Pine.SGI.3.94.991222094621.329897A-100000@xxxxxxxxxxxxxxxxxxxx>
Reply-to: Brian Hall <brianw.hall@xxxxxxxxxx>
Sender: owner-lkcd@xxxxxxxxxxx
Since Intel & Alpha will be sharing the dump_header_t strucure, I thought there
might be a problem with using 64 bit values on the Intel side, so I just added
fields for Alpha matching Alpha's dh_regs. If this isn't a problem, I can just
remove dh_esp and dh_eip from this structure. However, then the naming
convention will match Alpha's dh_regs and not Intel's...

Is there a reason we couldn't just store the pc & sp for either
platform into the appropriate slot in pt_regs here?

IOW, remove dh_esp, dh_eip, dh_pc, dh_ps, and pick the variable name based on
the platform, i.e. in arch-alpha/vmdump.c:

pt_regs->ps = sptr;
pt_regs->pc = &&dump_here;

Of course the code called after __dump_execute would need to refer to the
registers this way also. Or will this not work because pt_regs gets overwritten?



OK, here is my proposed change to dump_header_t.:


typedef struct _dump_header_s {
        /* the dump magic number -- unique to verify dump is valid */
        uint64_t             dh_magic_number;

        /* the version number of this dump */
        uint32_t             dh_version;

        /* the size of this header (in case we can't read it) */
        uint32_t             dh_header_size;

        /* the level of this dump (just a header?) */
        uint32_t             dh_dump_level;

        /* the size of a Linux memory page (4K, 8K, 16K, etc.) */
        uint32_t             dh_page_size;

        /* the size of all physical memory */
        uint64_t             dh_memory_size;

        /* the start of physical memory */
        uint64_t             dh_memory_start;

        /* the end of physical memory */
        uint64_t             dh_memory_end;

        /* the esp for i386 systems -- MOVE LATER */
        uint32_t             dh_esp;

        /* the eip for i386 systems -- MOVE LATER */
        uint32_t             dh_eip;
        
        /* the program counter for Alpha systems -- ADDED */
        uint64_t             dh_pc;

        /* the stack pointer for Alpha systems -- ADDED */
        uint64_t             dh_ps;

        /* the number of pages in this dump specifically */
        uint32_t             dh_num_pages;

        /* the panic string, if available */
        char                 dh_panic_string[DUMP_PANIC_LEN];

        /* the time of the system crash */
        struct timeval       dh_time;

        /* the utsname (uname) information */
        struct new_utsname   dh_utsname;

        /* the dump registers */
        struct pt_regs       dh_regs;

        /* the address of the current task */
        struct task_struct  *dh_current_task;

} dump_header_t;


On 22-Dec-1999 Matt Robinson wrote:
> On Fri, 24 Dec 1999, Brian Hall wrote:
>|>That fixed the vmdump.h problem. Now it actually compiles, with warnings
>|>(implied casts). I notice that dh_esp and dh_eip are 32 bits wide; they will
>|>need to be 64 bit for Alpha; and the other uint32_t(s) in vmdump.c 
>|>(__dump_execute) will also need to be uint64_t(s), and the changes
>|>propagated, correct?
>|>
>|>Now, should I go ahead and change dump_header_t to (choose one):
>|>1) make dh_esp,etc uint64_t(s) in the header;
> 
> I'd make them whatever the dh_esp and dh_eip equivalents are in the
> pt_regs structure for SP and PC.
> 
>|>2) add fields specifically for alpha;
>|>3) do #1 and change them to dh_sp and dh_pc while I'm at it?
> 
> Do the name change while you're at it.  I'll change things in our patch.

--
Brian Hall <brianw.hall@xxxxxxxxxx>
http://www.bigfoot.com/~brihall
Linux Consultant

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