This is the mail archive of the
mailing list for the GDB project.
Re: A copy/save command ...
- From: Michael Snyder <msnyder at redhat dot com>
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Fri, 04 Jan 2002 14:05:23 -0800
- Subject: Re: A copy/save command ...
- Organization: Red Hat, Inc.
- References: <3C341E2D.email@example.com>
Andrew Cagney wrote:
> To toss out an idea. One of those oft mentioned missing features is a
> command to read/write binary data to/from GDB's target memory. There is
> the load command, but that works on object files (readable via BFD).
> Anyway, I've two vague thoughts on the syntax/semantics:
> 1. (gdb) copy <expression> <file>
> The result of <expression> is written to the raw file. This expoits the
> fact that GDB stores an expression in target form in host memory.
> Consequently, the copy command just writes that raw data to the file.
> 2. (gdb) copy <address> <length> <file>
> or (gdb) copy/<length> <address> <file>
> or similar. A more traditional <address>/<length> approach.
> ``copy/<length>'' comes from ``x/<length>''.
> better suggestions welcome.
How about (gdb) unload <filename> <?offsets?>
Not sure what options you might want, but load has offsets, so
unload might want them as well. Maybe an option to specify
file format (srec?)
I once wrote a "reload" command that was an optimized version of "load":
it would iterate thru the object file sections, ignore the read-only
and for each writeable section it would do a CRC and compare what was
in target memory. Only if they differed, it would download that
You might do something similar (assuming you had an object file):
iterate thru the sections, take the memory ranges for the writeable
ones, and copy those ranges to your output file (perhaps in a
format such as srec which GDB already knows how to reload later).