This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: malloc in inferior
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