From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hiro Sugawara To: "'Grant Edwards'" , Kevin Buettner Cc: gdb@sources.redhat.com Subject: RE: dump memory to file Date: Wed, 22 Aug 2001 11:18:00 -0000 Message-id: X-SW-Source: 2001-08/msg00193.html 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 >