This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH: gdb/mi + doco] -var-update


Daniel Jacobowitz writes:
 > For the future, I'd appreciate it if you didn't post partial patches
 > this way; I went back and dug up the right diffs, which isn't hard, but
 > is error-prone.  But I can handle it :-)

OK.

 > My version of TCL really did not like your testcase.  Did you attach
 > the right patch?  This one referenced var1 in the regexp but not in the
 > command, so it seems that it couldn't have passed.  And it added some
 > weird trailing whitespace.

Thats strange, I don't know how it passed.  I must have got the initial output
using var1 but earlier tests failed until I added extra backslashes etc.  I'll
take another look.

 > This patch includes the missing files, and I redid the varobj change in
 > a pedantically different way.  Thanks for catching my goof there, by
 > the way.  And caught a bad argc check on -var-list-children that I
 > think you picked up from me at some point.

Your change is clearly more object oriented.  I don't know why varobj.c is in
the gdb directory: it's only really used by mi-cmd-var.c.  How about moving it
into the mi directory, or even merging it with mi-cmd-var.c to form one file?
That way all the static functions currently in varobj.c will be automatically
accessible to the functions currently in mi-cmd-var.c.

 > How's it look?  If it looks good to you, I'll check it in, and then you
 > can commit the documentation and we can work out what happened to your
 > testcase.

Yes, it looks good to me.  Perhaps I can test it more fully once you've
committed it.  Now that the hectic release schedule of GDB has slowed down, I
think this is a good way to work.  I'm not sure that you will agree, though.

 > Also, this is for later, but I noticed some inconsistency in reviewing
 > the docs:
 > 
 > -stack-list-locals
 >    --no-values doesn't print types.
 >    --simple-value prints the types for everything, even complex values.
 >    --all-values doesn't print types.
 > 
 > -var-list-children always prints types, regardless of the PRINT_VALUES
 > option given.
 > 
 > -var-update never prints types, regardless of the PRINT_VALUES option.

Previously -stack-list-locals and -var-update didn't print types
while -var-list-children did.
 
For -stack-list-locals, I added the type so that I could display that in
the locals buffer instead of the value(s) for complex types. The user
could then examine the values with variable objects if he wished.

 > Should some of those be cleaned up?  At a guess, I'd make
 > -stack-list-locals --all-values print types, and -var-update
 > --all-values or --simple-values.  Didn't think about it much though.

I think the behaviour should be governed by use not consistency.  I don't
really have an opinion though as I will only use:

-stack-list-locals --simple-values
-var-list-children --all-values
-var-update --all-values

If "-var-update --all-values" prints types, I can easily arrange for Emacs
to ignore it.

Nick


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]