Dumping to a remote host by makedumpfile.

[nhorman at redhat.com (Neil Horman)]

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?
> 
There is, I think its the -E option.
Neil

> 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?
> 
> Dave
> 
> 

-- 
/***************************************************
 *Neil Horman
 *Software Engineer
 *Red Hat, Inc.
 *nhorman at redhat.com
 *gpg keyid: 1024D / 0x92A74FA1
 *http://pgp.mit.edu
 ***************************************************/