This is the mail archive of the
mailing list for the GDB project.
Re: gdb with python support still get crash on showing uninitialized local variables
- From: AndrÃ PÃnitz <andre dot poenitz at nokia dot com>
- To: ext Tom Tromey <tromey at redhat dot com>, "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Fri, 5 Nov 2010 18:12:27 +0100
- Subject: Re: gdb with python support still get crash on showing uninitialized local variables
- References: <4CB66700.email@example.com> <firstname.lastname@example.org> <email@example.com>
On Saturday 16 October 2010 00:38:23 you wrote:
> >>>>> "AndrÃ" == AndrÃ PÃnitz <firstname.lastname@example.org> 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
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)
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