This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] varobj.c c_describe_child
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