Discussing the next GDB release (GDB 7.0?)

Discussing the next GDB release (GDB 7.0?)

[Joel Brobecker]

Hello,

It's been a while since the last release, and I'd like to start
discussing the next release...

I checked the ``Next Release'' page in our Wiki and it mentions
documetation action-items mostly for non-stop and MI [Pedro,
Vladimir]. I think that this part will be relatively pain free.

To me, the only major deciding factor will be Python support.
We decided to delay a bit the release to give our Python support
a little bit of time to mature. I think that a little status
report on this project, and maybe suggestions as to what we'd
like to add to the FSF tree would be a nice starting point for
discussion.

I also propose that the next release has version number 7.0.
If everyone agrees, I'll try to create a wiki page for this
release, and move the action items from the "next release"
page to this page.

Anything else that you'd like to be put on the list for
this release?

-- 
Joel

Re: Discussing the next GDB release (GDB 7.0?)

[Eli Zaretskii]

> Date: Thu, 15 Jan 2009 07:45:52 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> 
> To me, the only major deciding factor will be Python support.

Right.

> I also propose that the next release has version number 7.0.

Agreed.

Re: Discussing the next GDB release (GDB 7.0?)

[Vladimir Prus]

Joel Brobecker wrote:

> Hello,
> 
> It's been a while since the last release, and I'd like to start
> discussing the next release...
> 
> I checked the ``Next Release'' page in our Wiki and it mentions
> documetation action-items mostly for non-stop and MI [Pedro,
> Vladimir]. I think that this part will be relatively pain free.

Especially given that it's done :-)

- Volodya

Re: Discussing the next GDB release (GDB 7.0?)

[Joel Brobecker]

> I also propose that the next release has version number 7.0.
> If everyone agrees, I'll try to create a wiki page for this
> release, and move the action items from the "next release"
> page to this page.

Page created: http://sourceware.org/gdb/wiki/GDB_7.0_Release

(I also removed the link to the gdb-6.7 release, it's still findable
by using the search I think).

I've already added the two items we just discussed:
  - PR 9747 from Pierre
  - the assert in get_frame_arch.

Vladimir, would you and Pedro mind doing reviewing GDB_Next_Release
and move what's left to do to the 7.0 page? (and delete the stuff that's
already been done?).  [Thank You!]

-- 
Joel

Re: Discussing the next GDB release (GDB 7.0?)

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.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
Joel> discussion.

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
  scenarios.)
* 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
  pretty-printing glue

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.

Tom

Re: Discussing the next GDB release (GDB 7.0?)

[Daniel Jacobowitz]

On Thu, Jan 15, 2009 at 10:16:43AM -0700, Tom Tromey wrote:
> 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 :-)

Sounds good to me.

I'd also like to have the inlining support in 7.0; it's in my court to
respond to Mark K.'s objections, but Stan seems to have volunteered to
lend me a hand... :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: Discussing the next GDB release (GDB 7.0?)

[Joel Brobecker]

> > 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 :-)
> 
> Sounds good to me.

Sounds good to me too.  On my end, I'd like to have as much as you
guys think is ready for prime-time. What I would like to avoid is
publishing something based on one API and then later having to
amend that API...  It's nice to hear that the pretty-printing
feature is already in use...

> I'd also like to have the inlining support in 7.0; it's in my court to
> respond to Mark K.'s objections, but Stan seems to have volunteered to
> lend me a hand... :-)

All GDB Maintainers: Feel free to add stuff to the new page. I don't
want the list to be incomplete because I missed one message...

-- 
Joel

Re: Discussing the next GDB release (GDB 7.0?)

[Thiago Jung Bauermann]

El jue, 15-01-2009 a las 10:16 -0700, Tom Tromey escribió:
> 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'd like to see those in as well. My concern is that supporting creation
of new commands and functions without exposing useful bits of GDB to
Python would be of limited usefulness... That's why I was thinking of
submitting other patches first like frames, symbols, blocks etc (though
I concede they may need some reshaping or polishing first).

To start small, submitting a patch for frame support and convenience
functions would already allow implementation of $caller_is... What do
you think?


-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

Re: Discussing the next GDB release (GDB 7.0?)

[Joel Brobecker]

> > 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'd like to see those in as well.
[...]
> To start small, submitting a patch for frame support and convenience
> functions would already allow implementation of $caller_is... What do
> you think?

I would love to see as much mature python support as possible in
the first release. It's more a matter of how much we can submit
and review before we branch. Go ahead, submit the patches and we
will try to review them.

We have yet to make a decision on when to branch&release, but I still
don't have enough elements to make a decision. To be announced later...

-- 
Joel

Re: Discussing the next GDB release (GDB 7.0?)

[Thiago Jung Bauermann]

El jue, 29-01-2009 a las 16:42 -0800, Joel Brobecker escribió:
> > To start small, submitting a patch for frame support and convenience
> > functions would already allow implementation of $caller_is... What do
> > you think?
> 
> I would love to see as much mature python support as possible in
> the first release. It's more a matter of how much we can submit
> and review before we branch. Go ahead, submit the patches and we
> will try to review them.

Great. I'll submit them as RFC and we can discuss on the list to decide
what is and what isn't mature and merge-worthy.
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

Re: Discussing the next GDB release (GDB 7.0?)

[Tom Tromey]

>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:

Tom> I think a reasonable goal would be to ship the Python-based
Tom> pretty-printing feature.
[...]

Tom> I'm happy to start submitting the remaining patches from the list.

I just wanted to post to explain why there have not been any
pretty-printing patches forthcoming.  After feedback from users, we're
changing the way that pretty-printers are looked up.  This should not
take too long to change (I don't have a target date, but Phil is
actively working on it), and I think it is fairly important to get
this in shape before putting the code into gdb.

Tom

Re: Discussing the next GDB release (GDB 7.0?)

[Joel Brobecker]

> I just wanted to post to explain why there have not been any
> pretty-printing patches forthcoming.  After feedback from users, we're
> changing the way that pretty-printers are looked up.  This should not
> take too long to change (I don't have a target date, but Phil is
> actively working on it), and I think it is fairly important to get
> this in shape before putting the code into gdb.

I agree. After thinking about it and collecting feedback, I think
that we should plan for a "GCC Summit" release sometime around
early June, maybe late May.  So far, I think we're still in good shape
to make that date.

I'll update the release page in the GDB website.

-- 
Joel

Re: Discussing the next GDB release (GDB 7.0?)

[David Daney]

Joel Brobecker wrote:
> Hello,
> 
> It's been a while since the last release, and I'd like to start
> discussing the next release...
> 

Acknowledging that these things can change, do you have a tentative 
release date in mind?

[...]

> Anything else that you'd like to be put on the list for
> this release?

Hardware watch support for mips{,el,64,64el}-linux.  The kernel support 
is in as of 2.6.28, but my gdb patches need a little work.  I will try 
to have them ready soon.

David Daney

Re: Discussing the next GDB release (GDB 7.0?)

[Joel Brobecker]

> Acknowledging that these things can change, do you have a tentative 
> release date in mind?

Not yet, no - this will depend on how fast the Python gurus think
they can get the Python included. I don't want to push them, though.

> Hardware watch support for mips{,el,64,64el}-linux.  The kernel support 
> is in as of 2.6.28, but my gdb patches need a little work.  I will try 
> to have them ready soon.

OK. I won't add it to our list, as I don't think this is blocking
for the release. Just cleanup and submit quickly, and then hassle us
to review the patches, ok?

-- 
Joel

Re: Discussing the next GDB release (GDB 7.0?)

[teawater]

Hi Joel,

Do we need process record and replay in 7.0 release?
It's in submit process.

Thanks,
Hui

On Fri, Jan 16, 2009 at 01:36, Joel Brobecker <brobecker@adacore.com> wrote:
>
> > Acknowledging that these things can change, do you have a tentative
> > release date in mind?
>
> Not yet, no - this will depend on how fast the Python gurus think
> they can get the Python included. I don't want to push them, though.
>
> > Hardware watch support for mips{,el,64,64el}-linux.  The kernel support
> > is in as of 2.6.28, but my gdb patches need a little work.  I will try
> > to have them ready soon.
>
> OK. I won't add it to our list, as I don't think this is blocking
> for the release. Just cleanup and submit quickly, and then hassle us
> to review the patches, ok?
>
> --
> Joel

Re: Discussing the next GDB release (GDB 7.0?)

[teawater]

And catch syscall? I think it hang too.

On Fri, Jan 16, 2009 at 07:53, teawater <teawater@gmail.com> wrote:
> Hi Joel,
>
> Do we need process record and replay in 7.0 release?
> It's in submit process.
>
> Thanks,
> Hui
>
> On Fri, Jan 16, 2009 at 01:36, Joel Brobecker <brobecker@adacore.com> wrote:
>>
>> > Acknowledging that these things can change, do you have a tentative
>> > release date in mind?
>>
>> Not yet, no - this will depend on how fast the Python gurus think
>> they can get the Python included. I don't want to push them, though.
>>
>> > Hardware watch support for mips{,el,64,64el}-linux.  The kernel support
>> > is in as of 2.6.28, but my gdb patches need a little work.  I will try
>> > to have them ready soon.
>>
>> OK. I won't add it to our list, as I don't think this is blocking
>> for the release. Just cleanup and submit quickly, and then hassle us
>> to review the patches, ok?
>>
>> --
>> Joel
>

Re: Discussing the next GDB release (GDB 7.0?)

[Joel Brobecker]

Hi Teawater,

> > Do we need process record and replay in 7.0 release?
> > It's in submit process.

> And catch syscall? I think it hang too.

Neither of these features seem critical to me, but that's only
a personal opinion. As GDB Maintainer, I think of my role as being
the technician that implements the recommendations of the GDB
Maintainers. If the maintainers think this is critical, then
I'll add them to the list as blocking for the release.

That being said, this does not mean that they will not make it
for the release. If they get checked in before we branch, then
they're in...

Regarding the "process record" series of patches, I hesitate to
review them, because I know there has been some discussion that
I had to zap because I was too busy at the time. Hopefully the
persons involved in the discussion at the time can also review
your patches.  If not, I'll be home by the end of the month -
could you send me personally the links to the discussions and
the patches, and I'll try to take a look.

Regarding the "catch syscall", same thing. There was a long debate,
and I zappped it. Same suggestion.

-- 
Joel

Re: Discussing the next GDB release (GDB 7.0?)

[teawater]

Thanks Joel,

About process record, there were a lot of discussion with it and most
of them were fixed.
So in the third time submit, I think most parts of process record are
OK.  But after that, I didn't get approve (I just got the approve of
doc from Eli).

And I think "catch syscall" meet the same problem too.  Sérgio send 3
PINGs for third submit.

Please help us with it.

The follow links are for process record and replay submit first time:
http://sourceware.org/ml/gdb-patches/2008-11/msg00096.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00097.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00098.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00099.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00100.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00101.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00102.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00103.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00104.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00105.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00106.html

The follow links are for process record and replay submit second time:
http://sourceware.org/ml/gdb-patches/2008-11/msg00394.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00395.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00396.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00397.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00398.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00399.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00400.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00401.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00402.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00403.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00404.html

The follow links are for process record and replay submit third time:
http://sourceware.org/ml/gdb-patches/2009-01/msg00125.html
http://sourceware.org/ml/gdb-patches/2009-01/msg00126.html
http://sourceware.org/ml/gdb-patches/2009-01/msg00127.html
http://sourceware.org/ml/gdb-patches/2009-01/msg00128.html
http://sourceware.org/ml/gdb-patches/2009-01/msg00129.html
http://sourceware.org/ml/gdb-patches/2009-01/msg00130.html
http://sourceware.org/ml/gdb-patches/2009-01/msg00131.html
http://sourceware.org/ml/gdb-patches/2009-01/msg00132.html
http://sourceware.org/ml/gdb-patches/2009-01/msg00133.html
http://sourceware.org/ml/gdb-patches/2009-01/msg00134.html

The follow links are for 	'catch syscall' feature submit first time:
http://sourceware.org/ml/gdb-patches/2008-09/msg00583.html
http://sourceware.org/ml/gdb-patches/2008-09/msg00584.html
http://sourceware.org/ml/gdb-patches/2008-09/msg00585.html
http://sourceware.org/ml/gdb-patches/2008-09/msg00587.html
http://sourceware.org/ml/gdb-patches/2008-09/msg00586.html

The follow links are for 	'catch syscall' feature submit second time:
http://sourceware.org/ml/gdb-patches/2008-11/msg00016.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00019.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00017.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00020.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00018.html

The follow links are for 	'catch syscall' feature submit third time:
http://sourceware.org/ml/gdb-patches/2008-11/msg00449.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00450.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00451.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00452.html
http://sourceware.org/ml/gdb-patches/2008-11/msg00453.html

Thanks,
Hui


On Fri, Jan 16, 2009 at 11:39, Joel Brobecker <brobecker@adacore.com> wrote:
> Hi Teawater,
>
>> > Do we need process record and replay in 7.0 release?
>> > It's in submit process.
>
>> And catch syscall? I think it hang too.
>
> Neither of these features seem critical to me, but that's only
> a personal opinion. As GDB Maintainer, I think of my role as being
> the technician that implements the recommendations of the GDB
> Maintainers. If the maintainers think this is critical, then
> I'll add them to the list as blocking for the release.
>
> That being said, this does not mean that they will not make it
> for the release. If they get checked in before we branch, then
> they're in...
>
> Regarding the "process record" series of patches, I hesitate to
> review them, because I know there has been some discussion that
> I had to zap because I was too busy at the time. Hopefully the
> persons involved in the discussion at the time can also review
> your patches.  If not, I'll be home by the end of the month -
> could you send me personally the links to the discussions and
> the patches, and I'll try to take a look.
>
> Regarding the "catch syscall", same thing. There was a long debate,
> and I zappped it. Same suggestion.
>
> --
> Joel
>

Re: Discussing the next GDB release (GDB 7.0?)

[Tom Tromey]

>>>>> "teawater" == teawater  <teawater@gmail.com> writes:

teawater> And I think "catch syscall" meet the same problem too.  Sérgio send 3
teawater> PINGs for third submit.

Based on recent traffic on the archer list, I think it will need a
new submissions -- a few bugs were found.

Tom

RE: Discussing the next GDB release (GDB 7.0?)

[Marc Khouzam]

> From: Joel Brobecker
> Sent: Thursday, January 15, 2009 10:40 PM
> 
> > > Do we need process record and replay in 7.0 release?
> > > It's in submit process.
> 
> > And catch syscall? I think it hang too.
> 
> Neither of these features seem critical to me, but that's only
> a personal opinion. As GDB Maintainer, I think of my role as being
> the technician that implements the recommendations of the GDB
> Maintainers. If the maintainers think this is critical, then
> I'll add them to the list as blocking for the release.
> 
> That being said, this does not mean that they will not make it
> for the release. If they get checked in before we branch, then
> they're in...

For what its worth, I can't speak to the level of criticality of 
process record and replay, but we would really like to see this in 
the 7.0 release.  

I am almost ready with the Eclipse support for it (I manually 
applied the patches to GDB) and plan on doing a demo at EclipseCon.  
From what I was told, reverse debugging generates a lot of interest 
in people and would be a great addition to GDB.

Great work on the whole Reverse Debugging feature and
Process Record and Replay!

Marc

RE: Discussing the next GDB release (GDB 7.0?)

[Jakob Engblom]

> For what its worth, I can't speak to the level of criticality of
> process record and replay, but we would really like to see this in
> the 7.0 release.
> 
> I am almost ready with the Eclipse support for it (I manually
> applied the patches to GDB) and plan on doing a demo at EclipseCon.
> From what I was told, reverse debugging generates a lot of interest
> in people and would be a great addition to GDB.
> 
> Great work on the whole Reverse Debugging feature and
> Process Record and Replay!

I wonder if record/replay and reverse debugging are one and the same feature
from the perspective of inclusion in gdb 7.0?  It seems so from the above?
Logically, they can be separated into at least five parts:

* revexec support in gdb-serial

* reveexec support in MI

* revexec support in the gdb kernel

* record/replay as one way to effect revexec for the case of
x86-linux-user-process

* revexec from external sources, such as VMWare, Simics, and other simulators

Which parts of these are currently under consideration for inclusion in the
first 7.0 release?

Best regards,

/jakob

_______________________________________________________

Jakob Engblom, PhD, Technical Marketing Manager

Virtutech                   Direct: +46 8 690 07 47   
Drottningholmsvägen 22      Mobile: +46 709 242 646  
11243 Stockholm             Web:    www.virtutech.com 
Sweden
________________________________________________________
  

Re: Discussing the next GDB release (GDB 7.0?)

[teawater]

On Wed, Jan 21, 2009 at 02:25, Jakob Engblom <jakob@virtutech.com> wrote:
>> For what its worth, I can't speak to the level of criticality of
>> process record and replay, but we would really like to see this in
>> the 7.0 release.
>>
>> I am almost ready with the Eclipse support for it (I manually
>> applied the patches to GDB) and plan on doing a demo at EclipseCon.
>> From what I was told, reverse debugging generates a lot of interest
>> in people and would be a great addition to GDB.
>>
>> Great work on the whole Reverse Debugging feature and
>> Process Record and Replay!
>
> I wonder if record/replay and reverse debugging are one and the same feature
> from the perspective of inclusion in gdb 7.0?  It seems so from the above?
> Logically, they can be separated into at least five parts:

For now in gdb-cvs-head:

>
> * revexec support in gdb-serial

I think your mean is remote.c (GDBRSP)? This part is OK.

>
> * reveexec support in MI

I think Marc can answer this question. :)

>
> * revexec support in the gdb kernel

I think this part is OK.


>
> * record/replay as one way to effect revexec for the case of
> x86-linux-user-process

Process record and replay is in submit process.


>
> * revexec from external sources, such as VMWare, Simics, and other simulators


I think sim soft need RSP, right?  I think this part is OK.


Thanks,
Hui

Re: Discussing the next GDB release (GDB 7.0?)

[teawater]

Hi Jakob,

I think maybe you can use reverse debug function in gdb-cvs-head with
simics.  It will help us a lot. :)

Thanks,
Hui

On Wed, Jan 21, 2009 at 08:18, teawater <teawater@gmail.com> wrote:
> On Wed, Jan 21, 2009 at 02:25, Jakob Engblom <jakob@virtutech.com> wrote:
>>> For what its worth, I can't speak to the level of criticality of
>>> process record and replay, but we would really like to see this in
>>> the 7.0 release.
>>>
>>> I am almost ready with the Eclipse support for it (I manually
>>> applied the patches to GDB) and plan on doing a demo at EclipseCon.
>>> From what I was told, reverse debugging generates a lot of interest
>>> in people and would be a great addition to GDB.
>>>
>>> Great work on the whole Reverse Debugging feature and
>>> Process Record and Replay!
>>
>> I wonder if record/replay and reverse debugging are one and the same feature
>> from the perspective of inclusion in gdb 7.0?  It seems so from the above?
>> Logically, they can be separated into at least five parts:
>
> For now in gdb-cvs-head:
>
>>
>> * revexec support in gdb-serial
>
> I think your mean is remote.c (GDBRSP)? This part is OK.
>
>>
>> * reveexec support in MI
>
> I think Marc can answer this question. :)
>
>>
>> * revexec support in the gdb kernel
>
> I think this part is OK.
>
>
>>
>> * record/replay as one way to effect revexec for the case of
>> x86-linux-user-process
>
> Process record and replay is in submit process.
>
>
>>
>> * revexec from external sources, such as VMWare, Simics, and other simulators
>
>
> I think sim soft need RSP, right?  I think this part is OK.
>
>
> Thanks,
> Hui
>

Re: Discussing the next GDB release (GDB 7.0?)

[Michael Snyder]

Jakob Engblom wrote:
>> For what its worth, I can't speak to the level of criticality of
>> process record and replay, but we would really like to see this in
>> the 7.0 release.
>>
>> I am almost ready with the Eclipse support for it (I manually
>> applied the patches to GDB) and plan on doing a demo at EclipseCon.
>> From what I was told, reverse debugging generates a lot of interest
>> in people and would be a great addition to GDB.
>>
>> Great work on the whole Reverse Debugging feature and
>> Process Record and Replay!
> 
> I wonder if record/replay and reverse debugging are one and the same feature
> from the perspective of inclusion in gdb 7.0?   It seems so from the above?
> Logically, they can be separated into at least five parts:
> 
> * revexec support in gdb-serial
> 
> * reveexec support in MI
> 
> * revexec support in the gdb kernel
> 
> * record/replay as one way to effect revexec for the case of
> x86-linux-user-process
> 
> * revexec from external sources, such as VMWare, Simics, and other simulators
> 
> Which parts of these are currently under consideration for inclusion in the
> first 7.0 release?

The first three are already in (except I'm a little fuzzy
about the state of MI).  Oh, and by the way (Eli and Joel),
I owe you a NEWS entry.

The fourth (process record/replay) is what's currently on the table
for discussion.

The fifth bullet item (reverse exec from external sources such as
VMware, Virtutech etc). doesn't require any approval or action on
the part of the gdb maintainers, unless it uncovers a bug or problem
in the gdb parts.  Y'all (including me) can just go to town!  ;-)

Re: Discussing the next GDB release (GDB 7.0?)

[Michael Snyder]

Marc Khouzam wrote:
>> From: Joel Brobecker
>> Sent: Thursday, January 15, 2009 10:40 PM
>>
>>>> Do we need process record and replay in 7.0 release?
>>>> It's in submit process.
>>> And catch syscall? I think it hang too.
>> Neither of these features seem critical to me, but that's only
>> a personal opinion. As GDB Maintainer, I think of my role as being
>> the technician that implements the recommendations of the GDB
>> Maintainers. If the maintainers think this is critical, then
>> I'll add them to the list as blocking for the release.
>>
>> That being said, this does not mean that they will not make it
>> for the release. If they get checked in before we branch, then
>> they're in...
> 
> For what its worth, I can't speak to the level of criticality of 
> process record and replay, but we would really like to see this in 
> the 7.0 release.  

Ditto!


> I am almost ready with the Eclipse support for it (I manually 
> applied the patches to GDB) and plan on doing a demo at EclipseCon.  
> From what I was told, reverse debugging generates a lot of interest 
> in people and would be a great addition to GDB.

Ditto.  Last year I gave a talk about being a GDB maintainer
at the Silicon Valley Linux User's Group, and the entire Q&A
period was taken up by "When can we get this reverse debugging
of which you speak?"

> 
> Great work on the whole Reverse Debugging feature and
> Process Record and Replay!
> 
> Marc

Re: Discussing the next GDB release (GDB 7.0?)

[Joel Brobecker]

> >For what its worth, I can't speak to the level of criticality of 
> >process record and replay, but we would really like to see this in 
> >the 7.0 release.  
> 
> Ditto!

I just got back home in Vancouver, so I haven't followed the list
too closely, but it looks like review of the associated patches
has started.  Otherwise, do you think you could lend a hand?

The parameters are as follow: I am trying to determine what's blocking
before we can start the release process. Other than that, I'm trying
to release as early as possible, because the last release was a long
while ago. Other than that, I am not opposed to any feature in the
next release - it's just a mtter of getting them in before we branch.
Once the branch is created, however, the Global Maintainers and I
will start moderating what goes to the branch.

-- 
Joel

Re: Discussing the next GDB release (GDB 7.0?)

[Joel Brobecker]

> Anything else that you'd like to be put on the list for
> this release?

Tom suggested PR/9711: Quadratic slowdown in backtrace command.
I added to the list because it is a regression compared to 6.8,
but the example given shows the heavy slowdown only with a very
large number of frames. I wonder if this can happen with a more
typical number of frames - I suspect that Paul (the submitter)
probably hit the problem in a real situation before coming up
with this reduced example...

Daniel, it looks like you started looking into it at some point.
Is this issue still on your list? What do you think about having it
fixed for the next release?

-- 
Joel

Re: Discussing the next GDB release (GDB 7.0?)

[Paul Pluzhnikov]

On Thu, Jan 15, 2009 at 7:46 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>> Anything else that you'd like to be put on the list for
>> this release?
>
> Tom suggested PR/9711: Quadratic slowdown in backtrace command.
> I added to the list because it is a regression compared to 6.8,
> but the example given shows the heavy slowdown only with a very
> large number of frames. I wonder if this can happen with a more
> typical number of frames - I suspect that Paul (the submitter)
> probably hit the problem in a real situation before coming up
> with this reduced example...

Correct.

It happened while debugging gdb+python on archer branch,
which I accidentally put into an infinite recursion.

This had quite a large number of frames, *and* there were more
parameters in each frame, so it took longer. IIRC, it took
about 15 minutes to get to the top of the stack, where the
"interesting" frames were.

I don't believe putting a program into infinite recursion is
very unusual; I've done it many times in the past :-(

And when that does happen, waiting minutes for GDB to unwind
stack is the last thing you want to do.

-- 
Paul Pluzhnikov

Re: Discussing the next GDB release (GDB 7.0?)

[Eli Zaretskii]

> Date: Thu, 15 Jan 2009 21:47:34 -0800
> From: Paul Pluzhnikov <ppluzhnikov@google.com>
> Cc: gdb@sourceware.org
> 
> This had quite a large number of frames, *and* there were more
> parameters in each frame, so it took longer. IIRC, it took
> about 15 minutes to get to the top of the stack, where the
> "interesting" frames were.

Wouldn't "bt -20" help here?  Or is that slow, too, for the same
reason?

Re: Discussing the next GDB release (GDB 7.0?)

[Daniel Jacobowitz]

On Fri, Jan 16, 2009 at 07:46:23AM +0400, Joel Brobecker wrote:
> Daniel, it looks like you started looking into it at some point.
> Is this issue still on your list? What do you think about having it
> fixed for the next release?

I think it does need to be fixed for the next release, but I can't
promise to find the time myself.  I have way less time for GDB work
nowadays than I'd wish for.  I'll try but if someone else wants
to investigate first...

-- 
Daniel Jacobowitz
CodeSourcery

Re: Discussing the next GDB release (GDB 7.0?)

[Joel Sherrill]

Joel Brobecker wrote:

> Anything else that you'd like to be put on the list for
> this release?
>   
I have run into a case where gcc svn miscompiles
psim on x86_64.  It is reported as GCC PR 38587.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38587

I know it is a gcc bug.  I don't think it is a blocker
for gdb 7.0. 

I wanted it to get a bit more attention that it is.  Someone
else may run into this as well.

If anyone has suggestions on narrowing it down so
someone can fix it, I am willing to do that.  Given that
psim is used to test cross gcc, this is a bigger issue
than it appears and might impact other code.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

Re: Discussing the next GDB release (GDB 7.0?)

[Joel Brobecker]

> I have run into a case where gcc svn miscompiles
> psim on x86_64.  It is reported as GCC PR 38587.
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38587
> 
> I know it is a gcc bug.  I don't think it is a blocker
> for gdb 7.0. 

Indeed. If the problem was appearing with a released version of GCC,
we might want to try to find a work-around (eg: compile that file
at -O0), and document the problem.

-- 
Joel

Re: Discussing the next GDB release (GDB 7.0?)

[Nathan Sidwell]

Joel,
> It's been a while since the last release, and I'd like to start
> discussing the next release...

> Anything else that you'd like to be put on the list for
> this release?

What about merging the multiprocess bits from the multiprocess branch? If we're
going for a major version increment, might as well have as many new features as
possible :)

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery

Re: Discussing the next GDB release (GDB 7.0?)

[Joel Brobecker]

> What about merging the multiprocess bits from the multiprocess branch?
> If we're going for a major version increment, might as well have as
> many new features as possible :)

That's an interesting feature to have - I would love to have it, as
any new feature, but can this be pushed to trunk in a reasonable
amount of time? Otherwise, the question becomes: Do we want to delay
the release for this feature? What are the limitations in the current
implementation?

Right now, I am guestimating we're two to three months away from branching.
I need to discuss this delay with the Python guys too...

-- 
Joel

Re: Discussing the next GDB release (GDB 7.0?)

[Nathan Sidwell]

Joel Brobecker wrote:
>> What about merging the multiprocess bits from the multiprocess branch?
>> If we're going for a major version increment, might as well have as
>> many new features as possible :)
> 
> That's an interesting feature to have - I would love to have it, as
> any new feature, but can this be pushed to trunk in a reasonable
> amount of time? Otherwise, the question becomes: Do we want to delay
> the release for this feature? What are the limitations in the current
> implementation?

Pedro has a much better handle on the state of that branch than me.

> Right now, I am guestimating we're two to three months away from branching.
> I need to discuss this delay with the Python guys too...

I planned to have CodeSourcery work on getting that branch merged by the end of
April.  Hitting the beginning of April is probably too soon.

Please let me know if there's more we can do to get multi-process into GDB 7

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery