Re: malloc in inferior

[Daniel Jacobowitz <drow@mvista.com>]

On Thu, May 29, 2003 at 01:18:23PM -0400, John S. Yates, Jr. wrote:
> From: "Daniel Jacobowitz" <drow@mvista.com>
> 
> [..SNIP..]
> 
> > > 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.
> 
> Well as it so happens I was writing a "user-defined
> command" to walk from a task control block out 3
> levels.  My command had to guard against instances
> when outer levels of the structure did not exist.
> In such cases it tried to provide a clear diagnostic.
> The task control block contains an char tcb_name[8]
> member.  Since at times there might not even be a
> task running there might not be a valid task name.
> Thus I had
> 
> $task_name = ""      // even this calls malloc
> $tcb = 0
> $ptr1 = 0
> $ptr2 = 0
> if TCD_Current_Task
>     $tcb = TCD_Current_Task
>     $task_name = TCD_Current_Task->tcb_name
> else
>     printf "no current task\n"
> end
> 
> if $tcb
>     $ptr1 = $tcb->tcb_ptr1
>     if ! $ptr1
>         print "task %s: tcb_ptr1 is null\n",$task_name
>     end
> end
> 
> if $ptr1
>     $ptr2 = $ptr1->xxx_ptr2
>     if ! $ptr2
>         print "task %s: xxx_ptr2 is null\n",$task_name
>     end
> end
> 
> ...
> 
> [..SNIP..]
> 
> > > 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.
> 
> No.  An object is only accessible in the inferior
> if its address has been 
> 
>   1) manifested (always true for string literals)
>   2) supplied to the inferior via assignment (to
>      inferior storage) or as an argument to an
>      inferior function call
> 
> [..SNIP..]

Hmm.  This might be possible.

Again, do you have a concrete example where GDB calls malloc() other
than strings?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer