[Crash-utility] Re: [PATCH 0/3] Display local variables & function parameters from stack frames

[Sharyathi Nagesh]

Dave
   Excuse me for overlooking this part of the code, I am attaching a fix 
to this, hope this fixes the issue.

Dave I have few observations regarding the points you have raised
mkdumpfile -c stripping the ELF Note for pt_regs:
    mkdumpfile won't be saving much by stripping ELF Notes of pt_regs 
information. It will be ~256 bytes * number of cpus which is not much. 
We will discuss with mkdumpfile developers to check out the possibility 
of retaining this ELF Note information.

Regarding CONFIG_FRAMEPOINTER
    We understand this is disabled so as to release one more 
register,bp, for general purpose operations and this is default. Ideally 
this information should have got saved in dwarf section, so 
theoretically speaking we should be able to unwind the x86/x86_64 dump 
even with out CONFIG_FRAMEPOINTER. But some how the stack unwinding is 
not as direct as it is in ppc64 we are re-looking into this implementation.

Regarding Exception Frame on the top of the stack frame
     As we understand if we have the pt_regs of the topmost stack we 
should be able to unwind to the next stack frame, even if top most stack 
frame is an exception frame, atleast in ppc64. We are not sure of x86 
and x86_64 we can relook into that too.

Please let me know your thoughts on this
Thanks
Sharyathi



Dave Anderson wrote:
> Dave Anderson wrote:
>> That all being said, here's what I can do for you.  I will take your new
>> functions that you've added to netdump.c, and their protos in defs.h,
>> and apply them to the next crash utility release.  Since they are not being
>> used by anybody but your module at the moment, it's harmless to add them,
>> and then you will not have to patch the crash sources at all in your
>> subsequent module patch/posts.
> 
> I take that back...
> 
> You're first going to have to fix this proposed netdump.c function:
> 
> +static void* get_x86_regs_from_elf_notes(struct task_context *tc)
> +{
> +        Elf32_Nhdr *note;
> 
> An x86 kdump can be either a 32-bit or 64-bit ELF vmcore, but the default
> is 64-bit.  You have defined only one "note" pointer as an Elf32_hdr pointer.
> 
> +        size_t len;
> +        char *pt_regs;
> +       ulong regs_size;
> +
> +       if((tc->task == tt->panic_task) ||
> +             (is_task_active(tc->task))){
> +               if (nd->num_prstatus_notes > 1)
> +                       note = (Elf32_Nhdr *)
> +                               nd->nt_prstatus_percpu[tc->processor];
> +               else
> +                       note = (Elf64_Nhdr *)nd->nt_prstatus;
> 
> And then above you determine first whether there is more than one prstatus 
> note (i.e., more than one cpu), and then based upon that you're assigning 
> the "note" pointer to the appropriate location.  But for the single-cpu 
> you make it an Elf64_Nhdr pointer?  I realize it's just used as a address
> value, but it's just not right.  (BTW, compile crash with "make warn"
> instead of just "make")  
> 
> Anyway, you can conceivably have these i386 combinations:
> 
>  1. single-cpu, a 32-bit ELF header, and 1 prstatus note  (netdump or kdump)
>  2. single-cpu, a 64-bit ELF header, and 1 prstatus note  (kdump only)
>  3. multiple-cpu, a 32-bit ELF header, and 1 prstatus note (netdump only)
>  4. multiple-cpu, a 32-bit ELF header, and more-than-one prstatus note (kdump)
>  5. multiple-cpu, a 64-bit ELF header, and more-than-one prstatus note (kdump)
> 
> But  below you just default to an Elf32_Nhdr structure:
> 
> +
> +               len = sizeof(Elf32_Nhdr);
> +               len = roundup(len + note->n_namesz, 4);
> +               pt_regs = (void *)((char *)note + len +
> +                       MEMBER_OFFSET("elf_prstatus", "pr_reg"));
> +       /* NEED TO BE FIXED: Hack to get the proper alignment */
> +               pt_regs +=4;
> +       }
> +       else
> +               error(FATAL, "\n cannot determine register set for the task %s"
> +                       "bailing out\n ", tc->comm);
> +       return pt_regs;
> 
> You'll first need to determine whether it's a 32-bit or 64-bit header
> being used, and then whether to to point to the single prstatus note or 
> to the correct one in the NR_CPUS-bounded array of prstatus notes.
> 
> Dave
> 
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility

-------------- next part --------------
A non-text attachment was scrubbed...
Name: netdump_fix.patch
Type: text/x-diff
Size: 1377 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20090527/a08f9c86/attachment.bin>