A copy/save command ...

A copy/save command ...

[Andrew Cagney]

Hello,

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.

enjoy,
Andrew

Re: A copy/save command ...

[Daniel Jacobowitz]

On Thu, Jan 03, 2002 at 04:02:37AM -0500, Andrew Cagney wrote:
> Hello,
> 
> 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.

Perhaps not the best name - we want to be able to both read and write,
and it's not clear which way copy goes.  I don't want to end up doing
magic thinking that ``this looks like an address, not a filename'' to
figure that out.

Perhaps read/write?  But that's still not clear which way is which. 
load/store would be perfect but load is already used.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: A copy/save command ...

[Andrew Cagney]

> On Thu, Jan 03, 2002 at 04:02:37AM -0500, Andrew Cagney wrote:

>> better suggestions welcome.
> 
> 
> Perhaps not the best name - we want to be able to both read and write,
> and it's not clear which way copy goes.  I don't want to end up doing
> magic thinking that ``this looks like an address, not a filename'' to
> figure that out.


Lets be honest, ``copy'' is a really bad name.  For all those reasons 
and probably more :-)


> Perhaps read/write?  But that's still not clear which way is which. 
> load/store would be perfect but load is already used.


store is interesting.  Perhaps Michael's ``gcore'' command be called 
store?  Probably not since it is createing a core file and not an 
executable.  However as an alias it might make sense.

read/write are also interesting.  Good documentation and a help message 
should clarify the direction.  With read, care would be needed since 
``r'' is short for ``run''.

Andrew

Re: A copy/save command ...

[Frank Ch. Eigler]

cagney wrote:

> [...]  Lets be honest, ``copy'' is a really bad name.  For all those
> reasons and probably more :-) [...]

Consider:

(gdb) image save FILE RANGE [FORMAT]
(gdb) image restore FILE [ADDR]
(gdb) image compare FILE [ADDR]

where, say, RANGE could be 
    ADDR1 ADDR2
    "region 1" -- previously set memory region

and FORMAT could be some bfd-supported forms like "srec" or "binary".


- FChE

Re: A copy/save command ...

[Daniel Jacobowitz]

On Fri, Jan 04, 2002 at 12:39:52PM -0500, Frank Ch. Eigler wrote:
> 
> cagney wrote:
> 
> > [...]  Lets be honest, ``copy'' is a really bad name.  For all those
> > reasons and probably more :-) [...]
> 
> Consider:
> 
> (gdb) image save FILE RANGE [FORMAT]
> (gdb) image restore FILE [ADDR]
> (gdb) image compare FILE [ADDR]
> 
> where, say, RANGE could be 
>     ADDR1 ADDR2
>     "region 1" -- previously set memory region
> 
> and FORMAT could be some bfd-supported forms like "srec" or "binary".

I like it!  I'm not sure putting [FORMAT] is really worthwhile, though
- srec and binary would work, but we don't have enough information for
more complex formats.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: A copy/save command ...

[Andrew Cagney]

> 
> Consider:
> 
> (gdb) image save FILE RANGE [FORMAT]
> (gdb) image restore FILE [ADDR]
> (gdb) image compare FILE [ADDR]
> 
> where, say, RANGE could be 
>     ADDR1 ADDR2
>     "region 1" -- previously set memory region


I'm not sure what you mean by a previously set memory region.  Something 
like:

(gdb) image save myfile "region 1"

technically ``"region 1"'' is an expression that returns the address of 
the string ``region 1'' freshly malloc()d in target memmory.

--

I'm wondering what the semantics of ``restore'' are and how they differ 
from load in some cases.  Perhaphs ``(gdb) load <file> <offset>'' is 
syntatic sugar for one of the ``(gdb) image ...'' commands.

enjoy,
Andrew

Re: A copy/save command ...

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 624 bytes --]

Hi -

cagney wrote:
> > [...]
> > where, say, RANGE could be 
> >     ADDR1 ADDR2
> >     "region 1" -- previously set memory region
> 
> I'm not sure what you mean by a previously set memory region. [...]

I was referring to regions as managed by the "mem" command, as in

(gdb) mem 2000 2500
(gdb) info mem
[...]
(gdb) image store region 1 /my/file srec


> I'm wondering what the semantics of ``restore'' are and how they differ 
> from load in some cases.  Perhaphs ``(gdb) load <file> <offset>'' is 
> syntatic sugar for one of the ``(gdb) image ...'' commands.

Yes, quite possibly.


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: A copy/save command ...

[Andrew Cagney]

> Hi -
> 
> cagney wrote:
> 
>> > [...]
>> > where, say, RANGE could be 
>> > ADDR1 ADDR2
>> > "region 1" -- previously set memory region
> 
>> 
>> I'm not sure what you mean by a previously set memory region. [...]
> 
> 
> I was referring to regions as managed by the "mem" command, as in
> 
> (gdb) mem 2000 2500
> (gdb) info mem
> [...]
> (gdb) image store region 1 /my/file srec


Ok, it would need a different syntax though.  region and 1 are both 
valid addresses.  (not that I'm actually going to implement this part).


>> I'm wondering what the semantics of ``restore'' are and how they differ 
>> from load in some cases.  Perhaphs ``(gdb) load <file> <offset>'' is 
>> syntatic sugar for one of the ``(gdb) image ...'' commands.
> 
> 
> Yes, quite possibly.


I'm still wondering what the semantics of restore are ...

Andrew

Re: A copy/save command ...

[Michael Snyder]

Andrew Cagney wrote:
> 
> Hello,
> 
> 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
ones, 
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
section.

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).

Re: A copy/save command ...

[Michael Snyder]

"Frank Ch. Eigler" wrote:
> 
> cagney wrote:
> 
> > [...]  Lets be honest, ``copy'' is a really bad name.  For all those
> > reasons and probably more :-) [...]
> 
> Consider:
> 
> (gdb) image save FILE RANGE [FORMAT]
> (gdb) image restore FILE [ADDR]
> (gdb) image compare FILE [ADDR]
> 
> where, say, RANGE could be
>     ADDR1 ADDR2
>     "region 1" -- previously set memory region
> 
> and FORMAT could be some bfd-supported forms like "srec" or "binary".

If its a bfd-supported format such as srec, you can already use the
"load" command to put it back onto the target later.  Then all you
have to worry about is the opposite-of-load direction.

Re: A copy/save command ...

[Grant Edwards]

On Fri, Jan 04, 2002 at 02:07:09PM -0800, Michael Snyder wrote:
> "Frank Ch. Eigler" wrote:
> > 
> > cagney wrote:
> > 
> > > [...]  Lets be honest, ``copy'' is a really bad name.  For all those
> > > reasons and probably more :-) [...]
> > 
> > Consider:
> > 
> > (gdb) image save FILE RANGE [FORMAT]
> > (gdb) image restore FILE [ADDR]
> > (gdb) image compare FILE [ADDR]
> > 
> > where, say, RANGE could be
> >     ADDR1 ADDR2
> >     "region 1" -- previously set memory region
> > 
> > and FORMAT could be some bfd-supported forms like "srec" or "binary".
> 
> If its a bfd-supported format such as srec, you can already use the
> "load" command to put it back onto the target later.  Then all you
> have to worry about is the opposite-of-load direction.

For me, it's binary as often as not.  I haven't tried the
"load" command with binary data recently...

-- 
Grant Edwards
grante@visi.com

Re: A copy/save command ...

[Andrew Cagney]

> Hello,
> 
> 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>''.


First, lets forget I suggested ``copy'' :-)

The next thought was ``image load'' et.al. I think this overlaps the 
existing ``load'' command so, intead of having two very similar commands 
the load could just be tweeked as needed.

The next was a more explicit save / unload / ...  Michael's added 
``generate-core-file'' following following on from that my next guess is 
to change that command to:

	(gdb) generate core-file <file>

and then also add things like:

	(gdb) generate <target> <file> <arguments/sections>

for instance:

	(gdb) generate binary afile <address> <address> ...

(I think the word binary is unfortunate but that is what BFD calls it).

Andrew

Re: A copy/save command ...

[Frank Ch. Eigler]

cagney wrote:

> [...]
> The next was a more explicit save / unload / ...  Michael's added
> ``generate-core-file'' following following on from that my next guess
> is to change that command to:
> 	(gdb) generate core-file <file>
> and then also add things like:
> 	(gdb) generate <target> <file> <arguments/sections>
> for instance:
> 	(gdb) generate binary afile <address> <address> ...
> [...]

That looks good.  (Please consider "dump" or "emit" or "unload" or
"save" (yes, asking the tracepoint save function to be renamed) or
something instead of "generate" as the verb though.)


- FChE

Re: A copy/save command ...

[Vlasios Tsiatsis]

Someone has actually worked on GDB some time ago on a coomand like "save"
Take a look at the following meesage

http://sources.redhat.com/ml/gdb/2000-q1/msg00033.html

vlassis

Re: A copy/save command ...

[Eli Zaretskii]

> Date: Thu, 17 Jan 2002 19:27:55 -0500
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> 	(gdb) generate core-file <file>
> 
> and then also add things like:
> 
> 	(gdb) generate <target> <file> <arguments/sections>

That's not bad, but `generate' sounds a bit too general.  Perhaps a
more specific name would be better (we do ``generate'' files only,
right?).

Re: A copy/save command ...

[Andrew Cagney]

> Someone has actually worked on GDB some time ago on a coomand like "save"
> Take a look at the following meesage
> 
> http://sources.redhat.com/ml/gdb/2000-q1/msg00033.html
> 
> vlassis


Hmm, yes.  I suspect it unfortunatly ended up in limbo.  Given copyright 
concerns, I'll ignore it :-(

Andrew

Re: A copy/save command ...

[Andrew Cagney]

> cagney wrote:
> 
> 
>> [...]
>> The next was a more explicit save / unload / ...  Michael's added
>> ``generate-core-file'' following following on from that my next guess
>> is to change that command to:
>> (gdb) generate core-file <file>
>> and then also add things like:
>> (gdb) generate <target> <file> <arguments/sections>
>> for instance:
>> (gdb) generate binary afile <address> <address> ...
>> [...]
> 
> 
> That looks good.  (Please consider "dump" or "emit" or "unload" or
> "save" (yes, asking the tracepoint save function to be renamed) or
> something instead of "generate" as the verb though.)


Renameing ``save-tracepoints'' is possible using the deprecate command 
mechanism.  But perhaphs ``save'' should be reserved for GDB things. 
``unload'' reminds me too much of shared libraries.  But close to that 
is ``upload'' as suggested in the earlier thread the other is ``dump''. 
  I show both below:

	upload value <file> <expression>
	dump value <file> <expression>
		write the TARGET value of
		<expression> as a sequence
		of bytes.

	upload memory <file> <start> <length>

	dump memory <file> <start> <length>
		write memory from <start> to
		<start>+<length>-1 as bytes.
		While:
		  (*(char*)START)@LENGTH
		is equvalent this would be
		more efficient.

	upload core <file>
	dump core <file>
		Hmm, the latter parses well.

With the option:
	/a	append to file
(assuming I can get it to work and where applicable :-).

As for creating files in different formats objcopy can be used but that 
certainly doesn't preclude extra options being added.

Example:

	shell rm goo
	upload value/a goo (uint32) 0xdeadbeef
	upload value/a goo (uint8) 2
	upload value/a goo (uint8) 3

would write:

BE: de ad be ef 02 03
LE: ef be ad de 02 03

to a file.

thoughts?
Andrew

Re: A copy/save command ...

[Andrew Cagney]

>     dump memory <file> <start> <length>
>         write memory from <start> to
>         <start>+<length>-1 as bytes.
>         While:
>           (*(char*)START)@LENGTH
>         is equvalent this would be
>         more efficient.

> With the option:
>     /a    append to file
> (assuming I can get it to work and where applicable :-).

There is a bug here :-/

The parser can't easily differentiate (using LL1) between the two 
``/a'''s in:

	dump memory/a /a

so:

	dump memory <file> <start> <stop+1>
	append memory <file> <start> <stop+1>

?

Andrew

Re: A copy/save command ...

[Michael Snyder]

Edward Swarthout wrote:
> 
> From Daniel:
> > Perhaps read/write?  But that's still not clear which way is which.
> > load/store would be perfect but load is already used.
> 
> From FChE:
> > and FORMAT could be some bfd-supported forms like "srec" or "binary".
> 
> Couldn't adding binary support to load be considered the same as thing
> as "read"?

AFAIK load already supports binary format.  Also srec.

> Then the opposite of load, is dump.
> 
>    load/dump FILE SECTIONS(S)
> 
> The trick is to create a way to specify the layout and format of the
> desired sections.  Some sort of a reverse "info maint sections".
> 
> gdb> info maint sections
> Exec file:
>     `/h1/swarthou/prg/empty/empty1', file type elf32-powerpc.
>     0x10000074->0x10000098 at 0x00000074: .text ALLOC LOAD READONLY CO
>     0x10000098->0x10000098 at 0x00000098: .sdata2 ALLOC LOAD READONLY
>     0x100100a0->0x100100b0 at 0x000000a0: .data ALLOC LOAD DATA HAS_CO
>     0x100100b0->0x100100b0 at 0x000000b0: .sdata ALLOC LOAD DATA HAS_C
>     0x100100b0->0x100100b0 at 0x000000b0: .sbss HAS_CONTENTS
>     0x100100b0->0x100100c0 at 0x000000b0: .bss ALLOC
> Core file:
>     `/h1/swarthou/prg/empty/core', file type elf32-powerpc.
>     0x00000000->0x00000654 at 0x000000b4: note0 READONLY HAS_CONTENTS
>     0x00000000->0x000000c0 at 0x0000010c: .reg/14104 HAS_CONTENTS
>     0x00000000->0x000000c0 at 0x0000010c: .reg HAS_CONTENTS
>     0x00000000->0x00000108 at 0x00000600: .reg2/14104 HAS_CONTENTS
>     0x00000000->0x00000108 at 0x00000600: .reg2 HAS_CONTENTS
>     0x10000000->0x10000000 at 0x00001000: load1 ALLOC LOAD READONLY CO
>     0x10010000->0x10011000 at 0x00001000: load2 ALLOC LOAD HAS_CONTENT
>     0x7ffff000->0x80000000 at 0x00002000: load3 ALLOC LOAD CODE HAS_CO
> 
>  Then
> gdb> load BINFILE1 .bss
>  or
> gdb> dump BINFILE2 load1
>  would do the desired thing.
> 
> It would be natural to add core file support to load/dump too.
> 
> There is still the issue of how to specify the format (binary,
> elf-core, elf-object, srec, or other bfd type).  Maybe some borrow
> the syntax from objcopy or the loader.
> 
> - Ed
> 
> Ed.Swarthout@motorola.com
> Somerset Design Center

Re: A copy/save command ...

[Edward Swarthout]

> 
> I've been playing with load/store architectures for too long - I keep 
> thinking that the oposite of load is store ... :-(

Sure, but thats store register _to_ memory.

Lets see,

 load register from memory (actually .reg note section)
 load memory from (core) file

 store (save) register to memory
 dump (write) memory to (core) file

Re: A copy/save command ...

[Andrew Cagney]

Just some side notes.  I don't disagree with your logic.



> gdb> load BINFILE1 .bss


Some versions of load already have a syntax like:

	(gdb) load file [ <offset> ]

see symfile.c:generic_load()

>  or
> gdb> dump BINFILE2 load1
>  would do the desired thing.


I've been playing with load/store architectures for too long - I keep 
thinking that the oposite of load is store ... :-(


> It would be natural to add core file support to load/dump too.
> 
> There is still the issue of how to specify the format (binary,
> elf-core, elf-object, srec, or other bfd type).  Maybe some borrow
> the syntax from objcopy or the loader.


something like:

load/FORMAT
st^D^D dump/FORMAT

Trying to re-use objcopy would be a good idea (if helpful).

Andrew

Re: A copy/save command ...

[Edward Swarthout]

From Daniel:
> Perhaps read/write?  But that's still not clear which way is which. 
> load/store would be perfect but load is already used.

From FChE:
> and FORMAT could be some bfd-supported forms like "srec" or "binary".

Couldn't adding binary support to load be considered the same as thing
as "read"?

Then the opposite of load, is dump.

   load/dump FILE SECTIONS(S)

The trick is to create a way to specify the layout and format of the
desired sections.  Some sort of a reverse "info maint sections".

gdb> info maint sections
Exec file:
    `/h1/swarthou/prg/empty/empty1', file type elf32-powerpc.
    0x10000074->0x10000098 at 0x00000074: .text ALLOC LOAD READONLY CO
    0x10000098->0x10000098 at 0x00000098: .sdata2 ALLOC LOAD READONLY
    0x100100a0->0x100100b0 at 0x000000a0: .data ALLOC LOAD DATA HAS_CO
    0x100100b0->0x100100b0 at 0x000000b0: .sdata ALLOC LOAD DATA HAS_C
    0x100100b0->0x100100b0 at 0x000000b0: .sbss HAS_CONTENTS
    0x100100b0->0x100100c0 at 0x000000b0: .bss ALLOC
Core file:
    `/h1/swarthou/prg/empty/core', file type elf32-powerpc.
    0x00000000->0x00000654 at 0x000000b4: note0 READONLY HAS_CONTENTS
    0x00000000->0x000000c0 at 0x0000010c: .reg/14104 HAS_CONTENTS
    0x00000000->0x000000c0 at 0x0000010c: .reg HAS_CONTENTS
    0x00000000->0x00000108 at 0x00000600: .reg2/14104 HAS_CONTENTS
    0x00000000->0x00000108 at 0x00000600: .reg2 HAS_CONTENTS
    0x10000000->0x10000000 at 0x00001000: load1 ALLOC LOAD READONLY CO
    0x10010000->0x10011000 at 0x00001000: load2 ALLOC LOAD HAS_CONTENT
    0x7ffff000->0x80000000 at 0x00002000: load3 ALLOC LOAD CODE HAS_CO

 Then
gdb> load BINFILE1 .bss
 or
gdb> dump BINFILE2 load1
 would do the desired thing.

It would be natural to add core file support to load/dump too.

There is still the issue of how to specify the format (binary,
elf-core, elf-object, srec, or other bfd type).  Maybe some borrow
the syntax from objcopy or the loader.

- Ed

Ed.Swarthout@motorola.com
Somerset Design Center