This is the mail archive of the
mailing list for the GDB project.
Re: Discussing the next GDB release (GDB 7.0?)
- From: Tom Tromey <tromey at redhat dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb at sourceware dot org
- Date: Thu, 15 Jan 2009 10:16:43 -0700
- Subject: Re: Discussing the next GDB release (GDB 7.0?)
- References: <20090115034552.GF24105@adacore.com>
- Reply-to: tromey at redhat dot com
>>>>> "Joel" == Joel Brobecker <email@example.com> writes:
Joel> To me, the only major deciding factor will be Python support.
Joel> We decided to delay a bit the release to give our Python support
Joel> a little bit of time to mature. I think that a little status
Joel> report on this project, and maybe suggestions as to what we'd
Joel> like to add to the FSF tree would be a nice starting point for
There is a lot of code on the Python branch, but in my opinion not all
of it is merge-worthy yet.
I think a reasonable goal would be to ship the Python-based
pretty-printing feature. My reason for this particular goal is that
this code has been through a number of iterations, is in actual use by
various groups, and is an actually useful user-visible feature
(frequently requested in the last year, in fact :-)
This can be broken down into a number of patches:
* The VALUE_ADDRESS -> value_address patch. Though honestly I forget
why I wrote this.
* The struct type reference counting patch.
(This one is optional if you do not mind memory leaks in some
* The gdb.Type class
(A somewhat slimmed down form, since I am not sure that the wrappers
for blocks and symbols are ready.)
* Thiago's "get string" patch (pending on gdb-patches)
* More gdb.Value methods (also pending on gdb-patches)
* The gdb.Objfile class
* The "source -p" patch
* Finally, the hooks into printing and MI, and the actual
As a "stretch" goal we could consider support for new commands and
parameters implemented in Python, or convenience functions. I think
that code is also reasonably mature, useful, and independent from the
other Python bits.
I'm happy to start submitting the remaining patches from the list.
I'm also happy to explain what they are, in case you haven't been
following the archer list :).
Getting through them all may take a while. The good news is that a
lot of the infrastructure has already gone in.
Joel> I also propose that the next release has version number 7.0.
Joel> If everyone agrees, I'll try to create a wiki page for this
Joel> release, and move the action items from the "next release"
Joel> page to this page.
Sounds good to me.