Re: Patch: implement new dynamic varobj spec

[Vladimir Prus <vladimir@codesourcery.com>]

Vladimir Prus wrote:

> Tom Tromey wrote:
> 
>> This is the long-awaited dynamic varobj patch.
>> It implements the spec as described by Vladimir:
>> 
>>     http://sourceware.org/ml/gdb/2009-07/msg00088.html
>> 
>> .. with various minor changes we've discussed on that thread and
>> elsewhere.  I didn't give the follow-up URLs; I think that the doc patch
>> ought to be sufficient, and if it isn't, I will fix it up.
>> 
>> This has been in development for quite a while, including testing using
>> two different MI consumers (Vladimir's and one by Noam Yorav-Raphael).
>> 
>> There are three outstanding bugs.
>> 
>> * A dynamic varobj bug that I couldn't reproduce
>>   http://sourceware.org/ml/archer/2009-q3/msg00169.html
> 
> I've got with gdb-inside-gdb. What happens is:
> 
> - we have uninitialized std::vector<std::string> (did I already say that gcc produces
>   bogus debug info?)
> - The 'strings' at the address where supposed storage of the bogus vector is
>   point nowhere.
> - When Python code tries to pretty-print inaccassible memory, it gives:
> 
>         Traceback (most recent call last):
>         File "/home/ghost/Build/python/libstdcxx/v6/printers.py", line 469, in to_string
>         return self.val['_M_dataplus']['_M_p'].string (encoding, length = len)
>         RuntimeError: Cannot access memory at address 0xcf
> 
> - Inside GDB, pretty_print_one_value catches the above exception, and returns 0.
> - The rest of GDB fallbacks to printing the value as it would without Python
> pretty-printing. And with 'set print pretty 1', it pretty-prints the raw value.
> 
> I think there are two things worth fixing:
> 
> 1. set print pretty 1 should have no effect on MI. I can handle this part.

In fact, this is wrong idea. Normally, for structures we display {...} as immediate
value, set 'set print pretty 1' does not matter. The issue here is that when
pretty-printer fails, instead of falling back to standard MI behaviour -- display
of {...} as value and structure members as children -- we fall up with printing
the value and displaying it.

I guess this something that should be fixed independently of whether we special-case
some kinds of exceptions.

- Volodya