Re: malloc in inferior

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

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

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

Under the lazy paradigm gdb would grab any memory
in the inferior until it knew that it needed to.

In the case of the protected memory system, where
possible, an anonymous mmap call grabbing a few
megabytes might be significantly less invasive.

/john