Re: [patch] varobj.c c_describe_child

[Aleksandar Ristovski <aristovski@qnx.com>]

On 25/03/2010 2:29, Tom Tromey wrote:
>>>>>> "Aleksandar" == Aleksandar Ristovski<aristovski@qnx.com>  writes:
>
> Aleksandar>  Note that with latest gdb from HEAD it doesn't crash, I
> Aleksandar>  believe due to recent changes in lazy allocating the values,
> Aleksandar>  but it still seems wrong to keep all these intermediate
> Aleksandar>  values generated by adjust_value_for_child_access' in
> Aleksandar>  'all_values' list.
>
> I think these values will automatically be freed the next time an MI
> command is executed.  The call chain is mi_cmd_execute ->
> prepare_execute_command ->  free_all_values.

Yes. However, in gdb 6.8, it will not get a chance since it 
crashes before finishing creating children (on HEAD gdb it 
doesn't crash, I believe due to lazy mechanism).

>
> Or is the idea to limit the transient amount of memory used?
> I can't tell from the patch.

Yes, the idea is to reduce amount of transient memory.

>
> In that case, I think it would be more typical to use
> value_mark and value_free_to_mark.

What is happening (in a loop for each field of the struct) is:

- create value for the parent type (huge struct)
- create value for the field

and then repeat all that. I believe value_mark would not 
work since value that we do want to keep is interspersed 
with the ones we can discard.

Maybe the right fix is to create a varobj of pointed-to type 
as a child to pointer-to varobj, and then calculate children 
for this new varobj?

Or introduce "target_value" in varobj struct?

Not sure. The patch I proposed reduces the issue but  is not 
solving it completely.


Thanks,

-- 
Aleksandar Ristovski
QNX Software Systems