[Crash-utility] how to use crash utility to parse the binary memory dump

[Dave Anderson]

I've fixed/changed/added a few more items in this patchset:

 (1) The usage of GETBUF() has been removed from ramdump.c.  Although
     it still seems to work (by mistake/luck), the GETBUF/FREEBUF scheme
     is not initialized at that point.  And when it did get initialized,
     the buffer that was holding the RAM dump pathname got cleared.   
 (2) The allocation of the e_head buffer was incorrect because PAGESIZE()
     is not initialized at that point in time.
 (3) I removed the two "NOTE:" messages when the temporary ELF header
     or the new ELF vmcore file get created.  Instead, since the new ELF
     file option can take noticeable time, there is a please_wait() sequence.
     And if only the ELF header is created, the message is only shown if
     if CRASHDEBUG(1).
 (4) During the the intitial system banner, and subsequently in the
     "sys" command output, the temporary ELF header file name and the
     RAM dumpfile(s) are all displayed.
 (5) The "help -[nD]" output will show the normal kdump ELF information
     but will also have "ramdump data" appended, showing the relevant
     data from ramdump.c. 
 (6) The "crash --help" documentation has been reworded, and the analogous
     information added to the crash.8 man page.

It has been queued for crash-7.0.8:

  https://github.com/crash-utility/crash/commit/25b61f4a2ed31fe0fd2f55796e78e29fbb5045ff

Thanks,
  Dave




----- Original Message -----
> 
> Hello Vinayak,
> 
> This patch works and tests well, although I wish I had a more
> useful ARM64 sample dumpfile whose kernel has come up farther
> than the last one, and that either has kernel modules or at
> least one user-space task so I could verify the VTOP of those
> types of virtual addresses.
> 
> Here are a few minor issues with ramdump.c:
> 
> (1) It #includes <libelf.h>, which would require a new package to be
>     installed:
> 
>       $ rpm -qf /usr/include/libelf.h
>       elfutils-libelf-devel
>       $
> 
>     I changed it to #include <elf.h> (from glibc-headers) and it
>     compiles just fine.
> 
> (2) The ramdump_def structure:
>     
>     struct ramdump_def {
>             char *path;
>             int rfd;
>             ulong start_paddr;
>             ulong end_paddr;
>     };
> 
>     The start_paddr and end_paddr fields have to be 64-bits in
>     length to account for ARM kernels that have RAM beyond 4GB.
>     They start_paddr member gets assigned to a 64-bit p_paddr field
>     and the end_paddr field would overflow in a greater-than-4GB
>     scenario.  They should be ulonglong or physaddr_t types.
>   
>     Related to that, the start_paddr field should be intitialized
>     with htoll() instead of htol() just in case a 32-bit node
>     starts above the 32-bit threshold.
> 
> (3) The "Skipping dumpfile size check for ramdump" is unnecessary
>     given that the end_paddr is calculated based upon the size
>     of the RAM dump file itself.
> 
> (4) The "converting ramdump to kdump" message is unnecessary, and
>     the "Creating kdump ELF <filename>" should be different
>     if only an ELF header is created vs. whether a completely new
>     ELF file is being created.
>     
> I've made changes above to your patch with no problems, so there's no
> need for a re-post.  I'll keep playing around to see if anything
> else comes up.
> 
> Nice job!
> 
> Thanks,
>   Dave
> 
> 
> 
> 
> ----- Original Message -----
> > > In any case, if you use "htol()" instead of strtoul(), the user won't
> > > have to enter the "0x", because it will presume it's a hexadecimal
> > > address.
> > >
> > Done.
> > 
> > 
> > > However, you cannot put *nothing* as the offset value:
> > > So that also needs fixing.
> > Done.
> > 
> > >
> > > A few other questions/comments...
> > >
> > > When 32-bit x86 kdumps are created, they typically default to using
> > > the 64-bit ELF format.  That is required in case there is physical memory
> > > above the 4GB threshold, which cannot be described in a 32-bit ELF
> > > header.  Since 32-bit ARM can also be PAE, would it make more sense
> > > to *always* use 64-bit ELF headers for both ARM and ARM64?  I don't
> > > see why not, and it should simplify ramdump.c quite a bit.
> > That's right. I had to add a case in is_netdump() for EM_ARM.
> > 
> > >
> > > And thinking this through a bit more, to me it seems really wasteful
> > > to have to create a whole new dumpfile.  Even if it's only a temporary
> > > file, it's still seemingly an unnecessary duplication of disk space.
> > >
> > I agree.
> > 
> > > Here's an idea, not fully thought through, but seems like it could
> > > work when the "temporary" dumpfile option is used:
> > >
> > >  (1) Create a temporary file that *only* consists of the ELF header.
> > >  (2) Set a new RAMDUMP flag in pc->flags2.
> > >  (3) Pass that temporary ELF header file to is_kdump() as you do now.
> > >  (4) is_kdump() passes it to is_netdump(), and I believe that
> > >  is_netdump()
> > >      should parse just the ELF header and accept it as a KDUMP_ELF32 or
> > >      KDUMP_ELF64 file without even being aware that there's no physical
> > >      memory data attached.
> > >  (5) When kdump_init() is called, it passes through to netdump_init()
> > >      which calls check_dumpfile_size() -- which would need to look
> > >      at the RAMDUMP flag to do the right thing.
> > >  (6) And instead of using read_kdump(), copy it to a new read_ramdump()
> > >      function that reads from the original RAM dump image(s), figuring
> > >      out the file offsets accordingly.  Keep the new read_ramdump()
> > >      function in netdump.c so it can continue to use the "nd" vmcore_data
> > >      structure that is statically defined there.  read_ramdump() may have
> > >      to interact with function(s) in ramdump.c, or perhaps the
> > >      ramdump_def
> > >      structure can be shared with netdump.c somehow.
> > >
> > The attached patch contains these changes. Please review. I have tried
> > to keep read_ramdump()
> > within ramdump.c.
> > 
> > > There will presumably be a few other glitches that will require checking
> > > the new RAMDUMP flag, but I don't think that there would be anything that
> > > couldn't be overcome.  That really would be the ideal way to handle these
> > > files.
> > I have done some tests using both arm and arm64 ramdumps, including
> > the ones you had pointed out in previous emails.
> > I will do more tests and will let you know if I find any more bugs.
> > Please let me know if there are any specific tests to be done, which
> > can bring out these glitches.
> > 
> > Thanks,
> > Vinayak
> > 
> > --
> > Crash-utility mailing list
> > Crash-utility at redhat.com
> > https://www.redhat.com/mailman/listinfo/crash-utility
>