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

[vinayak menon]

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-raw-RAM-image-support.patch
Type: text/x-patch
Size: 15248 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20140729/861c1e58/attachment.bin>