[Crash-utility] add print raw data capability for rd

Lei Wen adrian.wenl at gmail.com
Mon Oct 3 14:48:31 UTC 2011


On Mon, Oct 3, 2011 at 9:40 PM, Dave Anderson <anderson at redhat.com> wrote:
>
>
> ----- 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 for detailed explaination. :)
I made another patch to address the mentioned issues.

Thanks,
Lei




More information about the Crash-utility mailing list