Vivek Goyal wrote: > On Thu, Jan 11, 2007 at 08:55:44AM -0500, Dave Anderson wrote: > > Vivek Goyal wrote: > > > > > On Wed, Jan 10, 2007 at 09:07:03AM -0500, Dave Anderson wrote: > > > > Just curious -- how difficult would it be to put the "-R" intelligence > > > > into the > > > > crash utility so that it could read the intermediate dumpfile.tmp file? > > > > > > > > Or do we want to consistently maintain "readablility" by both crash and > > > > gdb > > > > as the standard? (Other than when makedumpfile uses the "compressed" > > > > output format, which gdb can't read) > > > > > > > > > > IMHO, this piece fits more into makedumpfile only and should be > > > implemented > > > there. Lets not enable crash to read and understand another custom format. > > > Secondly, we should maintain compatibility with gdb for few reasons. > > > > > > - There are people out there who prefer using gdb. > > > - Sometimes crash is broken because of upstream changes and gdb > > > can still work in those situations. > > > - Sometimes gdb itself helps in debugging crash bugs. Sometimes > > > works > > > as reference that what should be the right output. > > > Thanks > > > Vivek > > > > Agreed on all counts... > > > > Keep in mind, however, that the use of the makedumpfile "-c" option will be > > fairly > > common, and gdb cannot read compressed dumpfiles. If you want to maintain > > gdb compatibility across the board, perhaps there should be yet another > > option > > that translates a compressed dumpfile into an ELF vmcore? > > > > Hi Dave, > > Good point. I think its a good idea that makedumpfile can take a compressed > file and convert it into ELF core file so that gdb can analyze it. > > Ken'ichi, any thoughts on this? > > > My only thought was that it may be be fairly trivial to implement support > > for the intermediate file format in crash. And it that's true, why not? > > > > I have no issues as long as crash functionality is not a replacement for > the functionality in makedumpfile. > > A side thought, how do we gain from this? Will we not end up maintaining > almost same code in two utilities? > >
Well, we effectively do that already -- there's significant overlap in the makedumpfile and crash code bases as it is. (When I look at the makedumpfile code, it's like deja vu all over again...) But that's not the point. The part of the diskdump code in the crash utility that handles the compressed data access is remarkably small. All I'm suggesting is that since makedumpfile's chore when dealing with the intermediate file is basically to put it back in the order used by the diskdump compressed file format, why couldn't the crash utility just be modified to deal with the intermediate file format as is? That way there'd be no need to worry about what's installed on the remote repository, it would just need to be some type of simple data warehouse. In any case, I'll let Ken'ichi decide whether it makes sense. Thanks, Dave _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
