RE: dump memory to file

[Hiro Sugawara <hsugawar@brocade.com>]

Though I vaguely remember, there's already a way to redirect the
print command's output to a file in the standard GDB. However,
one of our (ex-)customers found it was unacceptably slow for
dumping a large chunk of memory, especially on remote debugging.
And that was the motivation for me to develop the new commands,
I guess.

hiro

> -----Original Message-----
> From: Grant Edwards [ mailto:grante@visi.com ]
> Sent: Wednesday, August 22, 2001 11:04
> To: Kevin Buettner
> Cc: gdb@sources.redhat.com
> Subject: Re: dump memory to file
> 
> 
> On Wed, Aug 22, 2001 at 10:52:24AM -0700, Kevin Buettner wrote:
> 
> > > A while back I had asked if gdb could dump a section of target
> > > memory to disk (as bin, elf, hex, whatever).  The answer at the
> > > time was no -- is that still the case?  If I added such a
> > > command, would it be of interest to anybody else? (IOW, should
> > > I submit a patch?)
> > 
> > I think it'd be nice to provide a more general solution.  
> I.e, I think
> > it'd be nice if GDB had a facility whereby output from subsequent
> > commands would be redirected to a file.  Maybe something along the
> > following lines?
> > 
> > (gdb) redirect-output /tmp/foo
> > (gdb) x/10000x 0x01000
> > (gdb) print/x $pc
> > (gdb) x/100i $pc-200
> > (gdb) redirect-output STDOUT
> > 
> > And, it'd also be nice to redirect to be able to redirect to two or
> > more destinations at the same time...
> > 
> > (gdb) redirect-output /tmp/foo STDOUT
> 
> That would be really nice, particularly for printing large
> structures (or arrays of structures) for archival or automated
> analysis. But, I think the binary dump/restore function still
> needs to be there:
> 
>  1) I'd like to be able to dump data in a format understood by
>     objcopy.  That way, you can convert it to specific formats
>     needed by other tools (e.g. RPOM programmer), link it into
>     another program, etc.
> 
>  2) Redirecting output doesn't provide a way to load a chunk
>     from disk back to target memory.  I don't need to do this
>     nearly as often, but it would occasionally be handy.
> 
> -- 
> Grant Edwards
> grante@visi.com
>