Re: malloc in inferior

Daniel Jacobowitz
2003-05-29T16:09:35Z

On Thu, May 29, 2003 at 12:00:44PM -0400, John S. Yates, Jr. wrote:
>
> 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.

What can you usefully do with strings that doesn't communicate them to
the inferior?

For instance, assigning "set x = "abc"" must materialize it in the
inferior.

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

I didn't miss it; see above. It would have to happen every time the
inferior is _resumed_, too.

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

Which would, in a protected memory system, have to be allocated in the
child anyway. And you can't call malloc() before program
initialization necessarily.

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

Care to give another example of when GDB calls malloc? Strings are far
and away the most common.

--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer