On Mon, Oct 3, 2011 at 9:40 PM, Dave Anderson <anderson@xxxxxxxxxx> 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
