This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Patch: implement new dynamic varobj spec
- From: Vladimir Prus <vladimir at codesourcery dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Fri, 18 Sep 2009 13:29:37 +0400
- Subject: Re: Patch: implement new dynamic varobj spec
- References: <m3r5uejz4y.fsf@fleche.redhat.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