Bug 12806 - multi-level pretty-printing
Summary: multi-level pretty-printing
Status: NEW
Alias: None
Product: gdb
Classification: Unclassified
Component: python (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 24201 (view as bug list)
Depends on: 30816
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-25 18:13 UTC by Tom Tromey
Modified: 2023-09-26 15:38 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Tromey 2011-05-25 18:13:33 UTC
A frequently requested feature is the ability to do
"multi-level" pretty-printing.  The idea here is that a printer
can return a child which is of some synthetic type not existing
in the inferior; that way it can specify a multi-level display
of some kind.

One way to achieve this would be to make it possible for a
printer's child to itself be a printer; then use that printer
directly rather than attempting to convert to a value.
Comment 1 Andre' 2012-11-28 22:06:38 UTC
Another option would be to move over to the "fat script" approach of pretty printing (i.e. "do all in one go, top-down"). In that case the pretty printer for an object can directly and easily decide by itself which real or which artificial children, or grand-children, or completely unrelated data, it would like to print and recursively invoke the "main" pretty print function to get "standard behaviour" for the subitems. 

This would also solves issues related to missing MI variable updates for items whose pretty print result takes global state or unrelated data into account (see the example give in the thread triggered by http://sourceware.org/ml/gdb-patches/2012-11/msg00027.html).
Comment 2 Tom Tromey 2022-06-11 19:32:50 UTC
*** Bug 24201 has been marked as a duplicate of this bug. ***
Comment 3 Tom Tromey 2023-08-31 19:24:11 UTC
(In reply to Andre' from comment #1)
> Another option would be to move over to the "fat script" approach of pretty
> printing (i.e. "do all in one go, top-down").

I want to do something that's also relatively useful to DAP.
In DAP, the child of a variable may itself be a variable.
So separate objects are probably the most straightforward.
This is similar to varobj but not as bizarre.

A one-shot, full-tree approach loses laziness, which is part of DAP.
However it could be done "either direction", either by having an
object that hands tearoffs to gdb, or by eagerly iterating over
children.
Comment 4 Tom Tromey 2023-08-31 20:02:50 UTC
Also see https://sourceware.org/bugzilla/show_bug.cgi?id=30816#c2
Natvis has a similar feature to this.
Comment 5 Tom Tromey 2023-09-26 15:38:23 UTC
Now that the new base class is in, this could be done by
changing the varobj (and generic printing) code to recognize
when the 'children' method returns a ValuePrinter, and then
simply use that object.