Hi Dave,
1) what I talked about is pure 32bit (not with PAE, but should not be a problem with PAE)
64 bit ELF headers could also be in place.
but my first and important point is: get 32bit implementation right (rest will fall after that)
in other words, the design/framework has to be made in such a way that existing crash utility absorbs both ELF32 and 64 and even any other debugging format or not to mention for long term but 128 bit ELF format as well :)
kdump should be capable of reading it I think.
2) 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?
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?
currently I am setting function point to kdump, so I dont have separate readmem function.
3) 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?
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?
it looks more closer to the former one which you mentioned.
standalone ELF object. (Vmcore is ELF format anyway, so should be similar)
not sure about kdump format
though.
PS: It might take some time to post the patch because I wrote it in hurry to make it work at the first point:but now I have to think with the design perspective and more on long term perspective to make this framework scalable and get easily accommodated in crash utility architecture.
Regards,
Oza.
On Thursday, 29 May 2014 7:09 PM, Dave Anderson <anderson@xxxxxxxxxx> wrote:
----- 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
-- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
