Re: malloc in inferior

["John S. Yates, Jr." <jyates@netezza.com>]

From: "Daniel Jacobowitz" <drow@mvista.com>
To: "John S. Yates, Jr." <jyates@netezza.com>
Cc: "gdb" <gdb@sources.redhat.com>
Sent: Thursday, May 29, 2003 11:27 AM
Subject: Re: malloc in inferior


> On Thu, May 29, 2003 at 09:51:15AM -0400, John S. Yates, Jr. wrote:

[..SNIP..]

> > Why can gdb not allocate values within its own
> > address space?
> 
> Because it's not useful to do so.  Sure, trivial examples like
> print "foo" could be done this way; and it would be nice to do that. 
> But to do anything more complicated requires materializing them in the
> inferior.  Some optimization is missing but you can't get away from the
> problem that way.

Is there anything short of calling a function in the
target that requires materialization in the inferior?
I can perform an enormous amount of debugging without
ever thinking about trying to call a function.


> > I understand that to support calling functions
> > in the inferior gdb may have to materialize
> > values there.  But these should be pushed into
> > the inferior once it is clear that they need to
> > exist there.

I think this suggestion got missed.  Instead of today's
immediate materialization in the inferior against the
possibility that the value might be required there in
the future why not use a lazy approach?  Before calling
an inferior function push down any accessible objects.
 
> > And how can gdb possibly debug a multi-threaded
> > application with a thread-safe malloc?
> 
> This wasn't considered in the current design, true.  I'm open to
> suggestions.
> 
> > One possibility would be to add malloc and free
> > messages to the remote protocol.  Then a stub
> > could allocation memory in the proper address
> > space without interacting with the inferior's
> > environment.
> > 
> > Another would be to have a stub provide a block
> > of memory.  A query would determine the address
> > and size of this block.  Then gdb could manage
> > the memory entirely on its own.
> 
> For some stubs these would be useful; for the stubs I deal with, which
> sit in user space on normal OS's, rather less so.  The stub would end
> up calling malloc anyway.

This may be the case for the first suggestion.  The
second was that gdb have access to a chunk of memory
that it manages itself.  That is the allocation and
freeing would operator on structures in gdb's address
space, only the actual memory would exist in the
inferior.  In a remote stub the block of memory might
simply be a large static array.

> Personally, I'm of the opinion that we should solve this problem by
> changing the definitions: mark strings as ephemeral and let the user
> call malloc or strdup directly if they want something to last.  Or make
> it a set option.  I'm not sure how popular that idea would be; anyone
> else have a comment?

The problem is more general than just strings.

/john