This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Changes to varobj.c
> I think you've missed it. The patch was posted here:
>
> http://article.gmane.org/gmane.comp.gdb.patches/40822
>
> and the version I've checked in has no changes relative to the one
> I've posted.
It looks like it was attached in reply to a patch with the subject header
"[RFC][patch 0/9] Python support in GDB". I don't read everything posted to
gdb-patches and delete messages based on the subject which is why I must have
missed this one.
> Would you like to CC-d on all MI patches?
If you just give an indication in the subject header about the content, as you
have suggested, that should be enough - thanks.
> > I can see a stale comment before varobj_update:
> >
> > NOTE: This function may delete the caller's varobj. If it
> > returns TYPE_CHANGED,...
> >
> > (varobj_update no longer returns TYPE_CHANGED)
>
> You are right. On the other hand, why do delete varobj when its type
> changes, or in other words, why value_of_root uses varobj_create? I think
> I'll just stop it making do so,
If floating varobjs are used then var->root->exp changes when the frame changes
and using varobj_create is one way to get hold of this expression. I think if
you don't use varobj_create then you will have to use a chunk of it.
> together with the other planned change of
> making -var-create of floating varobj not fail when the expression cannot be
> parsed.
That's an independent matter though, right?
--
Nick http://www.inet.net.nz/~nickrob
PS I've just noticed that:
struct varobj **cv;
struct varobj **templist = NULL;
are no longer used in varobj_update.
I've updated my linked list patch to your changes and it looks cleaner. Using
a vector for result seems like a good idea, I just don't think it works for
varobj_list_children.