Re: [Crash-utility] add print raw data capability for rd
----- Original Message -----
Hi Dave,
>> > Hi,
>> >
>> > I recent make a patch which give the rd command to dump the raw data. With
this,
>> > we could then do the dump the specified range of memory to the file with
console's
>> > redirection feature like: rd -r 0x7000000 -e 0x8000000 > dump.img.
>> >
>> > What about this idea? Could it be accepted?
>> >
>> > Thanks,
>> > Lei
>>
>> I think it's a pretty good idea.
>>
>> However, one problem with the patch is that if you forget to append
>> the "> dump.img" part, it would end up spewing non-ASCII data to
>> the terminal. I would suggest using a construct like "-r dump.img",
>> which would force the user to supply a filename argument with the -r.
Good idea, I would send another patch to include this.
>>
>> Also, maybe you could write a more efficient output function that
>> ignores the "typesz", and fwrite()'s larger fixed-size blocks of
>> data until it reaches the end of the desired memory chunk.
Em... the typesz, may cannot be ignored... Since the count has been divided
by display type before passing to display_memory().
Sorry -- I should have been more clear on that point...
Using the "typesz" (-8, -16, -32, -64, or the architecture-default 32/64)
doesn't really make sense with respect to raw output. It shouldn't be
necessary for the user to first determine what the "typesz" is, and then
have to calculate the "count" argument based upon that.
All you want to do is dump some number of bytes to the output file, i.e.,
where the usage should simply be:
crash> rd -r outputfile <start-address> <byte-count>
or alternatively, but more verbosely,
crash> rd -r outputfile <start-address> -e <ending-address>
The "help rd" explanation of the default output size, and of the
"count" option, should both be modified to explain that "rd -r"
requires either a "count" argument expressed in bytes, or "-e addr".
Secondly, I'd prefer not to re-assign the global "fp" in this case,
because it gets tricky if you enter "ctrl-c" during the output phase.
On the other hand, when a new file is opened, and "ctrl-c" is entered
during the output phase, there needs to be a way for that file to
be closed.
Something like this should work:
+ case 'r':
+ flag |= DISPLAY_RAW;
+ tmpfp = fopen(optarg, "w");
+ if (tmpfp == NULL)
+ error(FATAL, "cannot open dump image\n");
+ else
+ pc->tmpfile2 = tmpfp;
+ break;
And then in your display_memory() section, call close_tmpfile2() when
it's complete. Then, if by chance the output gets interrupted by "ctrl-c",
close_tmpfile2() will automatically be called by restore_sanity(), so
you don't have to worry about it.
Lastly, when the output is successfully written out, there should be a
message indicating that "xxx bytes written from <address> to
<filename>".
Thanks,
Dave