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

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.

However, you cannot put *nothing* as the offset value: So that also needs fixing.

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.

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.

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.

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.