Re: gdb with python support still get crash on showing uninitialized local variables

[Andrà PÃnitz <andre dot poenitz at nokia dot com>]

On Saturday 16 October 2010 00:38:23 you wrote:
> >>>>> "AndrÃ" == Andrà PÃnitz <andre.poenitz@nokia.com> writes:
> 
> AndrÃ> However, I do not use the gdb version of the pretty printers for
> AndrÃ> the stability reason you just encountered, and because they
> AndrÃ> cannot (easily...) create several layers including possibly
> AndrÃ> "virtual" ones that do not correspond to actual objects on the
> AndrÃ> inferior side.
> 
> I don't understand this latter comment, but I would like to.
> Could you give an example?  Or explain it in more depth?

The MI varobject based infrastructure creates one level of information
at a time. So it is not easy to create displays of "virtual levels" or
items that do not actually "live" in the inferior. Displays like

  Name                       Value            Type

  someObject                  0x2312413        SomeType
      properties 
           property1            "MyName"          String      (stored in a member of the object)
           property2            Nov 11, 2010     Date       (perhaps in current locale)
           property3            "Some Street"    String      (perhaps coming from a database)
      children
           ...
      parents
           ...
      connections
           ...

are very hard to create in this world, yet such display can be _very_ 
convenient when debugging applications above the "bare metal" level.

I actually claim that certain displays are impossible to handle with the MI
varobject approach -- even under the assumption that it would work well
otherwise (i.e. handle anonymous structs, hidden variables in outer scope,
gracefully cope with uninitialized/corrupted data, need not several
roundtrips to setup, had a way to reduce repeated data etc)

I seriously believe that with full python scripting being available in gdb
there is no need to use MI varobjects at all. 

Unfortunately, gdb's own python based pretty printing does not use
this new freedom but is modeled very similar to the varobject setup 
and therefore shares (needlessly if I may add) some of the varobject 
shortcomings.

Andre'