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

[Dave Anderson]

----- Original Message -----
> >>
> >> Also, I suggested the "-o outputfile" option -- after which you could simply enter
> >> "crash vmlinux outputfile" -- because your implementation requires that the
> >> user must be aware of the base physical address value.
> >>
> >> Anyway, this all sounds good, so please post a patch.  And can you also make one of
> >> these dumpfiles available to me to download?
> >>
> >> Thanks,
> >>
> >>   Dave
> >
> > --
> > Crash-utility mailing list
> > Crash-utility at redhat.com
> > https://www.redhat.com/mailman/listinfo/crash-utility
> 
> Hi Dave,
> 
> Patch attached implements raw RAM image support. I have tested it with
> a ARM ramdump. Will test it with a arm64 ramdump tomorrow and will
> post the results.

I haven't tested this yet, but I do note that the patch doesn't
apply because it appears like you were working with crash-7.0.5?
In the future, please post patches against either the upstream
git development branch, or at least against the current upstream
release, currently crash-7.0.7.

> 
> With this change, a raw RAM image can be passed to crash in the following way.
> 
> ./crash [path to ram image] [path to vmlinux] --ram_start=[address] -o output_file
> 
> To start with I have assumed that, dump of a single memory node will
> be a single file. That means, the 2 RAM images (ddr1.bin and ddr2.bin
> which I guess belongs to a single node) mentioned in the first email
> of this mail chain, should be concatenated and passed as a single
> file. When multiple images are passed with multiple --ram_start, it
> will be considered as different memory nodes, like below.
> 
> ./crash [path to ram image of node 1] [path to ram image of node 2] [path to vmlinux] --ram_start=[start address of node 1] --ram_start=[start address of node 2] -o output_file

Anyway, before going any further, the whole command line user-interface
is too complex, verbose, and error-prone.  Also, the patch adds too much 
RAM-dump related stuff to main(), where the "nodes", "rams", "rd" and 
"elf_out" variables really belong in the ramdump.c file.  This is really
just another dumpfile type, and it should be handled in a similar manner
as the other types.

Now, breaking this down, what we have to handle during invocation in main() 
is one or more blocks of RAM that start at some physical address, i.e.,
one or more "ram at address" ordered pairs.  Why not have a single, 
uniquely-identifiable argument string that describes the whole entity?

Here is my counter-proposal, where the invocation would be something 
like this:

  $ crash vmlinux ramdump at address [-o output_file]

and if there are multiple images, make them a comma-separated list:

  $ crash vmlinux ramdump1 at address,ramdump2 at address [-o output_file] 

Then here in main(), handle it like the other "is_dumpfile_type()"
functions by passing the single argument string to an is_ramdump() 
function in your ramdump.c file:

        while (argv[optind]) {

+               if (is_ramdump(argv[optind]) {
+                       if (pc->flags & MEMORY_SOURCES) {
+                               error(INFO, "too many dumpfile arguments\n");
+                               program_usage(SHORT_FORM);
+                       }
+                       pc->dumpfile = ramdump_to_elf();
+                       if (is_kdump(pc->dumpfile, KDUMP_LOCAL)) {
+                               pc->flags |= KDUMP;
+                               pc->readmem = read_kdump;
+                               pc->writemem = write_kdump;
+                       } else {
+                               error(INFO, "malformed ELF dump file: %s\n",
+                                       pc->dumpfile);
+                               program_usage(SHORT_FORM);
+                       }
+                       continue;
+               }

                if (is_remote_daemon(argv[optind])) {
                        if (pc->flags & DUMPFILE_TYPES) {
                                error(INFO,
                                      "too many dumpfile/memory arguments\n");
                                program_usage(SHORT_FORM);
                        }
                        pc->flags2 |= REMOTE_DAEMON;
                        optind++;
                        continue;
                }

The is_ramdump() function can verify if it's a valid argument
by first checking for the required/unique "@" character in the 
argument string.  It can then parse the argument, and save the
required "nodes", "rams", etc. in a "ramdump_def" structure
that can be statically declared in ramdump.c.  You should also
have a dump_ramdump_def() function that can be called from
"help -[Nd]".

With respect to the [-o output_file], and given the potential 
simplicity of the argument string, I think it should be
optional.  You could do something like this in the getopt() 
handler, and have the ELF output_file name pre-stored in the 
ramdump_def structure:

+              case 'o':
+                       ramdump_elf_output_file(optarg);
+                       break;

If "-o output_file" is NOT used, then ramdump_to_elf() can
pass back the name of a temporary file.

> 
> I can share the memory dumps used.
> 
> Thanks,
> Vinayak

Great, thanks, I've got them...

I'd also really appreciate having a sample RAM dump from an ARM64
machine as well.

Thanks,
  Dave