Missing requirement in pretty-printer + MI specs?

[Doug Evans <dje at google dot com>]

Hi.

If I have a pretty-printer that implements the "children" API call,
then can the frontend can expect to iterate over each children?
And possible invoke the MI -var-create command for each child?

The docs of pretty_printer.children say this:

---snip---
 -- Function: pretty_printer.children (self)
     GDB will call this method on a pretty-printer to compute the
     children of the pretty-printer's value.

     This method must return an object conforming to the Python iterator
     protocol.  Each item returned by the iterator must be a tuple
     holding two elements.  The first element is the "name" of the
     child; the second element is the child's value.  The value can be
     any Python object which is convertible to a GDB value.

     This method is optional.  If it does not exist, GDB will act as
     though the value has no children.
---endsnip---

The docs of -var-create say this:

---snip---
      -var-create {NAME | "-"}
         {FRAME-ADDR | "*" | "@"} EXPRESSION
[...]
   EXPRESSION is any expression valid on the current language set (must
not begin with a '*'), or one of the following:

   * '*ADDR', where ADDR is the address of a memory cell

   * '*ADDR-ADDR' -- a memory address range (TBD)

   * '$REGNAME' -- a CPU register name

   A varobj's contents may be provided by a Python-based pretty-printer.
In this case the varobj is known as a "dynamic varobj".  Dynamic varobjs
have slightly different semantics in some cases.  If the
'-enable-pretty-printing' command is not sent, then GDB will never
create a dynamic varobj.  This ensures backward compatibility for
existing clients.
---endsnip---

Note that nowhere is there mention of any potential or necessary
relationship between the result returned by pretty_printer.children
and what to pass to -var-create for the child to express the child's
location.

So question: What does the frontend pass for EXPRESSION of children
of a pretty-printed c++ class?

There's nothing in the pretty_printer.children spec that says the name
returned has to be a c++ class member name (and thus the frontend could
pass *&class_var.child_name or some such).
And there's nothing in the pretty_printer.children spec that says the
result has to be an lvalue (and thus gdb could pass the location of
the value to -var-create from that).

Oversight?  Or am I missing something?

At the least the docs need to give more guidance on this topic.