RE: dump memory to file

RE: dump memory to file

[Hiro Sugawara]

Ah, our understanding of GPL was, "Okay, my change is now a part of
GDB. We are happy to give the source code to you at a nominal cost
if you purchase our binary. And you are free to use, modify, and/or
redistribute the source code, but we are not mandated to give away
the source for free to the general public."

I think the LynxOS license package already includes all the GPL
sources or LynuxWorks offers source CDs to its customers. But I am
no longer with them and do not know for sure...

hiro

> -----Original Message-----
> From: Grant Edwards [ mailto:grante@visi.com ]
> Sent: Wednesday, August 22, 2001 10:54
> To: Kevin Buettner
> Cc: Hiro Sugawara; gdb@sources.redhat.com
> Subject: Re: dump memory to file
> 
> 
> On Wed, Aug 22, 2001 at 10:43:42AM -0700, Kevin Buettner wrote:
> 
> > > Since gdb is GPL'd, and LynuxWorks is distributing the LynxOS
> > > version of gdb, then the sources must be available, right?
> > 
> > Right.
> > 
> > However, for such a change to be incorporated into GDB, the
> > author(s) of the change must have a copyright assignment in
> > place with the FSF. Sometimes it quite challenging to make sure
> > that all of the legal documents are signed by the right
> > people...
> 
> OK, let me see if I've got this: LynuxWorks can't not
> distribute the changes, and they can't prevent anybody else
> from distributing them, but the changes won't be incorporated
> into the official sources without a copyright assignment.
> 
> I just went through the whole copyright assignment thing with
> my employer so I could donate some stuff to eCos.  It took
> years and cost thousands of lives.
> 
> Well... it did take almost a year.
> 
> Unless LynuxWorks is already set up to do stuff like that, it
> would be easier for me to just impliment it on my own.  I
> suppose it won't hurt to ask them -- I'm pretty sure I've got a
> business card from that Embedded Systems Conference...
> 
> -- 
> Grant Edwards
> grante@visi.com
> 

Re: dump memory to file

[Grant Edwards]

On Wed, Aug 22, 2001 at 11:01:25AM -0700, Hiro Sugawara wrote:

> Ah, our understanding of GPL was, "Okay, my change is now a
> part of GDB. We are happy to give the source code to you at a
> nominal cost if you purchase our binary.

That's my understanding, also.

> And you are free to use, modify, and/or redistribute the source
> code, but we are not mandated to give away the source for free
> to the general public."

I believe so.

I was assuming that either a LynxOS customer would be willing
to give me a copy of the sources, or LynuxWorks would give me a
copy as a gesture of goodwill to the open source community (and
to a potential customer - I do embedded software for a living).

I wasn't planning on spending $5K (or whatever) to get the gdb
sources. :)

However, if they don't want to do the copyright assignment
(which is understandable, after going through the process
myself), then I'd rather add the feature myself (and get it
into the official sources) than maintain a patch in perpetuity
that adds the LynuxWorks features.

-- 
Grant Edwards
grante@visi.com

Re: dump memory to file

[Grant Edwards]

On Wed, Aug 22, 2001 at 03:38:20PM -0400, Jamie Guinan wrote:

> redirect-output is a neat idea, but I think dumping a section of
> target memory to a file is a different problem, and needs its
> own solution.  This is particularly valuable in embedded systems,

That's also when I've needed it.  Since the debugging hardware
doesn't have a trace buffer, I had to add SW tracing of
selected events (it needed to be in more-or-less real-time).
Then when I hit an error condition I stop execution and need to
dump out 4-8K event records and run them through some programs
to format and filter them.

Other times when working on DSPish type stuff I've needed to
dump out raw data for external analysis and verification.

> So having a 'dump-region' command would be a nice addition to
> GDB,

I think I'll start working on it this weekend.  It should be
pretty trivial -- assuming there are existing routines that
read/write target memory, and bfd routines that read/write
files in various formats.

-- 
Grant Edwards
grante@visi.com

Re: dump memory to file

[Jamie Guinan]

redirect-output is a neat idea, but I think dumping a section of
target memory to a file is a different problem, and needs its
own solution.  This is particularly valuable in embedded systems,
where I can remember at least two times it would have been valuable
to me:

 1) Saving the contents of a small (512k) memory-mapped flash device
    so I could examine it and restore it if necessary.  This was
    on an os-less MIPS 3k board with GDB over RS232.
 2) Grabbing a generated jpg (jfif) image out of memory on an
    MPC823-based digital camera prototype board, to verify that
    it was valid.  Also GDB over RS232.

In both cases I hacked up something to dump the memory region out of
a second serial port and gobble up the output on the host. :P

So having a 'dump-region' command would be a nice addition to GDB,
IMO.

-Jamie


On Wed, 22 Aug 2001, Kevin Buettner wrote:

> On Aug 22, 11:00am, Grant Edwards 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
> ...
>
> Kevin

Re: dump memory to file

[Andrew Cagney]

> Kevin Buettner <kevinb@cygnus.com> writes:
> 
> 
>> 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.
> 
> 
> It might be nice to have a stateless option.  For example using a
> variant of the standard shell syntax for appending to a file:
> (gdb) >>FILENAME COMMAND
> For example:
> (gdb) >>/tmp/foo x/10000x 0x01000
> 
> Though it is also useful for it to span mutliple commands.  One could
> so that if there is no command:
> (gdb) >>FILENAME

Yes, that is often suggested.  The syntax has consequences though, the 
expressions:

	(gdb) >>foo print 1 + 2

	(gdb) print 1 + 2 >> foo

are very different.  Anyway, there is still some initial leg work.

I've added your idea to PRMS.

	Andrew

Re: dump memory to file

[Kevin Buettner]

On Aug 22, 11:25am, Per Bothner wrote:

> > 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.
> 
> It might be nice to have a stateless option.  For example using a
> variant of the standard shell syntax for appending to a file:
> (gdb) >>FILENAME COMMAND
> For example:
> (gdb) >>/tmp/foo x/10000x 0x01000
> 
> Though it is also useful for it to span mutliple commands.  One could
> so that if there is no command:
> (gdb) >>FILENAME

I like this better than the syntax that I proposed.

Kevin

Re: dump memory to file

[Andrew Cagney]

For the transcript idea, have a look at the PRs:

http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=129&database=gdb&return_url=http%3A%2F%2Fsources.redhat.com%2Fcgi-bin%2Fgnatsweb.pl%3Fdatabase%3Dgdb%26category%3Dall%26severity%3Dall%26priority%3Dall%26responsible%3Dall%26state%3Dall%26ignoreclosed%3DIgnore%2520Closed%26class%3Dall%26synopsis%3Doutput%26multitext%3D%26columns%3Doriginator%26columns%3Dsynopsis%26cmd%3Dsubmit%2520query%26sortby%3DPR%26.cgifields%3Dcolumns%26.cgifields%3Doriginatedbyme%26.cgifields%3Dignoreclosed
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=128&database=gdb&return_url=http%3A%2F%2Fsources.redhat.com%2Fcgi-bin%2Fgnatsweb.pl%3Fdatabase%3Dgdb%26category%3Dall%26severity%3Dall%26priority%3Dall%26responsible%3Dall%26state%3Dall%26ignoreclosed%3DIgnore%2520Closed%26class%3Dall%26synopsis%3Doutput%26multitext%3D%26columns%3Doriginator%26columns%3Dsynopsis%26cmd%3Dsubmit%2520query%26sortby%3DPR%26.cgifields%3Dcolumns%26.cgifields%3Doriginatedbyme%26.cgifields%3Dignoreclosed
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=114&database=gdb&return_url=http%3A%2F%2Fsources.redhat.com%2Fcgi-bin%2Fgnatsweb.pl%3Fdatabase%3Dgdb%26category%3Dall%26severity%3Dall%26priority%3Dall%26responsible%3Dall%26state%3Dall%26ignoreclosed%3DIgnore%2520Closed%26class%3Dall%26synopsis%3D%26multitext%3Doutput%26columns%3Doriginator%26columns%3Dsynopsis%26cmd%3Dsubmit%2520query%26sortby%3DPR%26.cgifields%3Dcolumns%26.cgifields%3Doriginatedbyme%26.cgifields%3Dignoreclosed

to get a feel for what's involved.  I think it is very much as an 
incremental, mostly obvious, project (ideal for those mysteriously short 
winter nights North America is currently having [:-)]).

	Andrew

Re: dump memory to file

[Kevin Buettner]

On Aug 22, 12:53pm, Grant Edwards wrote:

> > However, for such a change to be incorporated into GDB, the
> > author(s) of the change must have a copyright assignment in
> > place with the FSF. Sometimes it quite challenging to make sure
> > that all of the legal documents are signed by the right
> > people...
> 
> OK, let me see if I've got this: LynuxWorks can't not
> distribute the changes, and they can't prevent anybody else
> from distributing them, but the changes won't be incorporated
> into the official sources without a copyright assignment.

Right.

> I just went through the whole copyright assignment thing with
> my employer so I could donate some stuff to eCos.  It took
> years and cost thousands of lives.
> 
> Well... it did take almost a year.

I know.  I can tell some similar stories from personal experience.

In my opinion, there are many worthwhile changes that don't make it
into the mainline sources because the legal hoop jumping is so
difficult.  Many people are more than happy to send you their changes
and tell you (in email) that these changes may be incorporated into
the the sources, but they are absolutely not interested in obtaining
the legal documents and then pushing these documents through the
appropriate corporate channels to be signed by all the right people.
Frequently too, the corporate lawyers need to become involved and
when this happens, it can drag out the process almost interminably.

> Unless LynuxWorks is already set up to do stuff like that, it
> would be easier for me to just impliment it on my own.  I
> suppose it won't hurt to ask them -- I'm pretty sure I've got a
> business card from that Embedded Systems Conference...

It certainly won't hurt to ask, but, since you already have an
assignment in place, it will almost certainly be quicker to
reimplement this functionality yourself.

Kevin

Re: dump memory to file

[Per Bothner]

Kevin Buettner <kevinb@cygnus.com> writes:

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

It might be nice to have a stateless option.  For example using a
variant of the standard shell syntax for appending to a file:
(gdb) >>FILENAME COMMAND
For example:
(gdb) >>/tmp/foo x/10000x 0x01000

Though it is also useful for it to span mutliple commands.  One could
so that if there is no command:
(gdb) >>FILENAME
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

RE: dump memory to file

[Hiro Sugawara]

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
> 

Re: dump memory to file

[Grant Edwards]

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

Re: dump memory to file

[Daniel Jacobowitz]

On Wed, Aug 22, 2001 at 10:52:24AM -0700, Kevin Buettner wrote:
> On Aug 22, 11:00am, Grant Edwards 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
> ...

This is on our internal wishlist bugs list :)

I was going to do it more like 'set logfile', although I hadn't
considered when you don't want it to show up on the screen.  Perhaps
'set log file <filename>' and 'set log only 1'?

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

Re: dump memory to file

[Kevin Buettner]

On Aug 22, 11:00am, Grant Edwards 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
...

Kevin

Re: dump memory to file

[Grant Edwards]

On Wed, Aug 22, 2001 at 10:43:42AM -0700, Kevin Buettner wrote:

> > Since gdb is GPL'd, and LynuxWorks is distributing the LynxOS
> > version of gdb, then the sources must be available, right?
> 
> Right.
> 
> However, for such a change to be incorporated into GDB, the
> author(s) of the change must have a copyright assignment in
> place with the FSF. Sometimes it quite challenging to make sure
> that all of the legal documents are signed by the right
> people...

OK, let me see if I've got this: LynuxWorks can't not
distribute the changes, and they can't prevent anybody else
from distributing them, but the changes won't be incorporated
into the official sources without a copyright assignment.

I just went through the whole copyright assignment thing with
my employer so I could donate some stuff to eCos.  It took
years and cost thousands of lives.

Well... it did take almost a year.

Unless LynuxWorks is already set up to do stuff like that, it
would be easier for me to just impliment it on my own.  I
suppose it won't hurt to ask them -- I'm pretty sure I've got a
business card from that Embedded Systems Conference...

-- 
Grant Edwards
grante@visi.com

Re: dump memory to file

[Kevin Buettner]

On Aug 22, 12:33pm, Grant Edwards wrote:

> Since gdb is GPL'd, and LynuxWorks is distributing the LynxOS
> version of gdb, then the sources must be available, right?

Right.

However, for such a change to be incorporated into GDB, the author(s)
of the change must have a copyright assignment in place with the FSF. 
Sometimes it quite challenging to make sure that all of the legal
documents are signed by the right people...

Kevin

Re: dump memory to file

[Grant Edwards]

On Wed, Aug 22, 2001 at 10:25:17AM -0700, Hiro Sugawara wrote:

> I have added such commands (both read and write) to the LynxOS
> version of GDB.

Neat.

> But I don't have the source...

That must have been hard. ;)

Since gdb is GPL'd, and LynuxWorks is distributing the LynxOS
version of gdb, then the sources must be available, right?

Any LynxOS customers on the list with sources?

-- 
Grant Edwards
grante@visi.com

RE: dump memory to file

[Hiro Sugawara]

I have added such commands (both read and write) to the LynxOS version of
GDB. But I don't have the source...

hiro

> -----Original Message-----
> From: Eli Zaretskii [ mailto:eliz@is.elta.co.il ]
> Sent: Wednesday, August 22, 2001 10:17
> To: grante@visi.com
> Cc: gdb@sources.redhat.com
> Subject: Re: dump memory to file
> 
> 
> > Date: Wed, 22 Aug 2001 11:00:16 -0500
> > From: Grant Edwards <grante@visi.com>
> > 
> > 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?
> 
> Yes :-(
> 
> > If I added such a
> > command, would it be of interest to anybody else? (IOW, should
> > I submit a patch?)
> 
> Yes, please!
> 

Re: dump memory to file

[Eli Zaretskii]

> Date: Wed, 22 Aug 2001 11:00:16 -0500
> From: Grant Edwards <grante@visi.com>
> 
> 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?

Yes :-(

> If I added such a
> command, would it be of interest to anybody else? (IOW, should
> I submit a patch?)

Yes, please!

dump memory to file

[Grant Edwards]

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

-- 
Grant Edwards
grante@visi.com