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

[Dave Anderson]

----- Original Message -----
> Hi Dave,
> 
> please find all my comments/clarifications/answers inline below.
> 
> 
> Since these raw DDR dumps seem to be an existing feature, it certainly
> seems worth implementing support for them.
> 
> I'm curious as to how these RAM dumps are currently used -- are there other
> tools that use them somehow?
> 
> Oza: there could be various tools which organisation might be writing to
> extract some logs, because they know the physical address
> where their private/public logs are stored.
> but none of the tools match the ability of crash utility as we all agree.
> 
> Are these DDR RAM dumps specific to embedded 32-bit ARM machines?
> 
> Oza: yes it depends, if it  is taken on armv7 then 32bit, if it is armv8,
> then 64 bit.

Are you thinking of supporting this feature for ARM64 as well?

Also, by any chance are you working with 32-bit ARM with PAE?  Currently
there is no support in the crash utility for ARM/PAE, and I have been 
hoping/waiting for ARM developers on this list to develop and post patches
supporting it.  Although it's unclear whether the kdump facility would
even work as-is with PAE, if this feature were available, it would be an
an alternative to kdump.  Anyway, if/when ARM/PAE support is put in place,
it would require the usage of 64-bit ELF headers for the 32-bit ARM/PAE dumps. 
But I'm getting ahead of myself...   ;-)

> 
>   
> Your feature sounds like a two-stage process:
> 
> (1) invoke crash utility -- passing it the base physical address of the
>      contiguous RAM dump, and the RAM dump file name(s) -- and then crash
>      creates a single ELF vmcore by pre-pending an ELF header and
>      concatenating
>      the dump file names.
> (2) invoke crash utility with vmlinux and newly-created vmcore.
> 
> Oza: yes it is 2 stage process, in the first stage crash utility will prepare
> something which crash utility itself can understand.
> which is nothing but ELF format, which every debugger typically understands
> (such as gdb)
> so I do that conversion at the first place.
> once that conversion is in place, crash utility core code takes it over and
> do the rest of the job. 
> 
> But you mention "generate object files" above.  Do you generate more than one
> file?
> 
> Oza: what I meant by object file is ELF file (ELF is something which is ready to be loaded/linked)
> this object file is nothing but one temporary file which crash utility will create...
> so if you give
> 
> crash ./vmlinux ./ramdump.bin kernel_base_address
> it woudl have created ramdump_ARM_ELF32  (temporary file) which crash utility will understand).
> after you exit crash, the temporary file would be deleted.
> 
> Is the newly-created vmcore subsequently recognized as a netdump or kdump
> ELF vmcore?  (i.e, handled by existing code in netdump.c)
> 
> Oza: it would be recognized as kdump (because I am currently using 'flags' of
> kdump), this is just to be aligned with crash internal implementations.
> 
> but nontheless it is a separate ELF file

OK, so then after you've created the temporary ELF file, crash internally
would end up setting the pc->readmem() pointers to read_kdump()?  Or do
you have your own readmem() function in the new ramdump.c file? 

> 
> Or does it create a new ELF-like dumpfile type that is handled in your new ramdump.c file?
> Oza: it is separate ELF file.
> 
> Could it be done in one step?  In other words, something like:
> 
>   $ crash vmlinux --ddr 80000000 ddr1.bin [ddr2.bin ...]
> 
> 
> Oza: this is precisely what is hapepning.
> 
> 
> where there would be a "virtual" ELF header created that could be used
> during the crash session?  (perhaps with an optional "-o outputfile"
> command line option to create/save it as an ELF vmcore)
> 
> Oza: virtual ELF header, and one more virtual program header would be created
> in temporary file which, the budle, called ELF32.
> optional command line option could be created as well. but currently we take
> bin file only.

Clarify one more thing please: is the temporary file simply a little standalone ELF
header that describes what's in the ddr.bin file?  Or do you concatenate the ELF
header and the ddr.bin file into a single, temporary, ELF vmcore file that
is essentially a clone of an ELF kdump dumpfile?

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