Re: [PATCH v1] gdb/DAP Introduce new methods to to Pretty Printers

[Tom Tromey <tromey@adacore.com>]

Simon> We could go the c++ standard library route here and define silly
Simon> (guard) names for everything we do, going forward.

gdb didn't reserve those, either.

Probably we should just add a second registration approach, one that
allows for future upgrades to the API.  It's just more work.

For DAP we could instead go the other route, and change the fallback
printers to use a fuller API, and then use a shim for existing printers.

>> These are exposed to Python as struct types, but we'd like to present
>> them as array types over DAP -- which is what is done for the CLI (via
>> special cases in the printing code) and also for MI (via varobj, though
>> I haven't actually implemented this for Rust yet).

Simon> I don't understand this part, I wrote a the documentation example,
Simon> that behaves like an dynamic array,
Simon> where pretty printer makes use of it's intimate knowledge of the
Simon> length, because I specifically had languages
Simon> like Rust in mind (or any other type of dynamic data).

Simon> Or do you mean that it should automatically understand when
Simon> it's a built in type, in the language? That would be nice. But would
Simon> that not introduce scope issues, like at what point do we stop?

gdb already does this.  I think the decisions are made per language, but
the general rule is that anything that can be created by the compiler is
normally supported by gdb, but anything in a library is expected to be
described by DWARF.

In Rust this mostly amounts to handling slices, but Ada has more
constructs that need special handling.

Simon> Wouldn't we have to 1st class-implement every language that has a
Simon> novel idea of representing (its own) standard data types? Or are for
Simon> instance
Simon> Rust slices represented specifically as a special type in DWARF that
Simon> we can recognize?

Normally the problem cases here are ones where there is a difference
between their representation in DWARF (e.g., a Rust slice or an Ada
unconstrained array are really struct types) and their meaning in the
language (these are both array-like constructs).

It's important that gdb have access to both of these things.  For
example, for a while GNAT could emit these kinds of arrays using
complicated location expressions -- but that makes it impossible to
create a new instance, because "undoing" the expressions is hard.

Simon> Either way, having a "smart pretty printer" sounds good, for the use
Simon> cases you've described, Ada strings,
Simon> Rust slices, etc - but my biggest question is how would we extend that
Simon> to arbitrary client code?

My thinking for the route forward is:

1. Add a new pretty-printer API that is clearly extensible and change
   the core to use it.  Old pretty-printers can be wrapped in shims.

2. Add support for these array-like objects to gdb.Value or maybe
   gdb.Type.  The idea here is to let Python be able to access the same
   things that gdb already knows.

Tom