This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: malloc in inferior


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]