The only way to obtain the value of a dynamic variable objects (= the return value of the pretty printer) is -data-evaluate-expresssion. However, -data- evaluate-expresion cannot be used for children of dynamic variable objects, since it is impossible to provide the required expression. The same should possibly returned in the results of -var-update and -var-list- children.
Could you clarify why you even want to use -data-evaluate-expression? Is that because you're adding pretty-printing to CDT and CDT, for some unknown reason, wants to display "variable details" for selected node in the variables tree? I am opposed to bloating the output of -var-update and or -var-list-children with full text (=CLI) rendering of that varobj, because such a design would require that GDB, fetches entire value from memory, always. It might be possible to introduce a separate command, or add --varobj option to -data-
Ok, I know it again. The problem was for pretty printers returning children. For instance, I have a collection and the pretty printer has a to_string method returning a summary (like "vector of lenght 2"). I would like to show this summary in the value column. -var-evaluate-expression only returns "{...}", probably since it has children. The only way of retrieving the summary, then, is to ask -data-evaluate-expression. But this works only as long as I'm able to provide the required expression, which I can only do as long as the variable of interest is not a child of another dynamic variable. So my request simply was that -var-evaluate-expression returns the result of the to_string method if it is backed by a pretty printer, regardless of whether it has children or not.
I actually though that this summary is both too huge and not particularly useful in a frontend. Say, the type of container is already knows, so all the summary say is report the size. Maybe, for containers, we want to show [N] as opposed to {...}?
(In reply to comment #3) > I actually though that this summary is both too huge and not particularly > useful in a frontend. Say, the type of container is already knows, so all > the summary say is report the size. Maybe, for containers, we want to show > [N] as opposed to {...}? Yes, from the requirements point, this is what I miss most. Currently, I have to expand the collection variable, if I just want to see how many elements it contains. And this doesn't work well, because in a large collection I also have to scroll to the end. Lets assume your proposal, how would you decide it's a collection? You take the display hint and if it's map or vector, it's collection. Next, how will you determine the number of childen? You cannot use the children method and use the iterate over all elements. If the collection is uninitialized, it may never return. Alternatively, you could add a new method to the pretty printers. It all boyls down to what our understanding of the to_string method is. Shall it just provide a short summary to identify an object, or shall it be used to dump all members in a string? I always interpreted as the first.
Hey Vladimir. I'm curious if this issue has been solved in one or the other way up to now. I was wondering if we could resolve those '{...}' for non-simple types in KDevelop's GDB support, and stumbled upon this bug entry. I think it's valid request to get some 'short summary' of non-simple types. Containers are the best example, it'd be good to know how many items they contain, without requesting the individual child items. Given the documentation about the pretty printer's to_string() method: "When printing from the CLI, if the to_string method exists, then gdb will prepend its result to the values returned by children. Exactly how this formatting is done is dependent on the display hint, and may change as more hints are added. Also, depending on the print settings (see Print Settings), the CLI may print just the result of to_string in a stack trace, omitting the result of children." => Here, to_string() is used unconditionally, children() is optional. Can't we transfer that kind of behavior to -var-evaluate-expression and friends as well?
Kevin, I don't know the current status of this issue 100%, but I don't know of any changes here. It is generally reasonable to see short summary of composite types, but still, what do we do if a composite type is big? Iterating over all children just to count them might be expensive.
Created attachment 10068 [details] Patch to always call to_string for pretty-printers
Patch sumbitted
*** Bug 28201 has been marked as a duplicate of this bug. ***
*** Bug 25153 has been marked as a duplicate of this bug. ***
Sending a patch.
The master branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3e8154778baf4df222d95e43a2c8fefdb17305f7 commit 3e8154778baf4df222d95e43a2c8fefdb17305f7 Author: Tom Tromey <tromey@adacore.com> Date: Thu May 26 08:33:05 2022 -0600 Put pretty-printers to_string output in varobj result PR mi/11335 points out that an MI varobj will not display the result of a pretty-printer's "to_string" method. Instead, it always shows "{...}". This does not seem very useful, and there have been multiple complaints about it over the years. This patch changes varobj to emit this string when possible, and updates the test suite. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11335
Fixed.