This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Patch: implement new dynamic varobj spec
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