This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Dumping memory to file


>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
>> Dan Hovang wrote:
>> > I've got an embedded system running eCos which I'm debugging
>> > using gdb over a serial line. I'm looking for ways to save blocks
>> > of memory to disk in the good old brutal fashion, for example,
>> > after hitting some breakpoing typing: (gdb) save *0x0400 *0x07e8
>> > "screendump"

>> Hello again,
>> I solved it by adding a command, savemem, which does just
>> that. It's most likely not a very good solution (it's my fist gdb
>> hack), but I'm attaching the diff anyway, in case someone is
>> interested.

Andrew> o While I personally have no opinion on
Andrew>   this command (commands are Fernando's domain) I suspect a
Andrew>   brief discussion about the command, its syntax and how it
Andrew>   fits into the overall GDB cli may be in order.

I intended to comment when Dan first posted.  As usual, lack of time
intervened.

I once had a similar need.  Instead of dumping raw memory, I needed to
dump data structures to a file.  I ended up running gdb underneath the
"script" utility to capture the output.  The fact that there are many
commands where users may want to capture output to a file indicates to
me that a generic mechanism is preferable to specialized commands.

That being said, the proposed "savemem" command is (if you look at it
in a warped sort of way) the opposite of the "load" command.  I think
it can be argued that it is an independent issue from capturing ouput
of commands.  For example, the SDS SingleStep debugger has a similar
command "upload" that reads memory and dumps it to a file.

The only change I might make to the command is a mechanism to control
how the memory region is dumped.  From the patch, I see the memory
region is written to the output file as raw bytes, but it might be
useful to also write out a s-record, intel hex, or some other format
that could be used in a subsequent load.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]