Re: Patch: implement new dynamic varobj spec

[Vladimir Prus <vladimir at codesourcery dot com>]

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.
2. pretty-printer for string should catch exception and return "<inaccessible>"
or some such. Alternatively, GDB should not fallback to regular display if
Python pretty-printer fails. Yet alternatively, GDB should distinguish between
different failure modes of Python pretty-printer, since memory access error 
likely to be caused by uninitalized data and should not cause fallback.

Does this make any sense?

- Volodya