[gdb-7.0 release] 2009-09-02 status and proposed plan

[gdb-7.0 release] 2009-09-02 status and proposed plan

[Joel Brobecker]

Hello everyone,

I think everyone is anxious to see the next release out as fast as
we can; it is going to be a major step forward compared to the previous
releases!

First, we need to make progress on the following documented issues:

  (a) Assert in frame.c:get_frame_arch
      Basically, we added an assertion to get_frame_arch, which should
      always be true. But to be safe, we decided to remove it from
      the release sources if the release branch was cut before we had
      enough time to field-test that change.  We added that assertion
      in January, so I think we can skip that item.  I don't think we
      ever tripped that assertion, did we?

  (b) Rename the python-support files to be 8.3-compliant.
      I thought that the change had been approved, but I see that
      the change has not been made.  Has it been approved? If yes,
      it is being held up because we don't know how to best rename
      files without disturbing git?

  (c) varobj support for Python pretty-printing
      Tom gave a quick status on IRC yesterday. It sounds like
      there isn't much left to do. Perhaps a quick update on the Wiki
      page to state exactly what's left would be nice.  Unless fixing
      the last thing or two might be faster ;-).

  (d) PR/9711: Quadratic slowdown for "where" command.
      Pending catastrophes, I should be able to fix that this week.

  (e) PR/9786: Typing "info frame" immediately after connecting to
      a remote target causes an assertion error on x86 GNU/Linux (32 bit). 
      That's a real regression.  I don't know that anyone ever looked
      at this issue. I did reproduce the issue many moons ago. I don't
      think it reproduces on x86_64.  Any taker?

  (f) bug in breakpoint commands: commands not evaluated outside of
      main command loop.
      http://sourceware.org/ml/gdb-patches/2008-07/msg00583.html
      There is a suggested patch, but needs looking at. Any taker?

If there are any issue that you know of that are *RELEASE-CRITICAL*
(build failure, regressions), please let us know, so we can decide
what to do, and possibly add it to the 7.0 TODO list. Anything else,
I suggest, should no longer be a priority for 7.0.

In terms of dates, I would like us to try to release sooner rather than
later. Can I suggest we try to shoot for Wed Sep 9th for the branch date,
and then try to release a couple of weeks after (that would be the 23rd)?

If there are any fixes that would be nice for the release but don't make
it to the 23rd, we can always have a corrective 7.0.1 release mid
December. Also, it sounds like a lot more new features are currently
being developed, and people are trying to make it for 7.0. I propose to
release 7.1 not too long after 7.0: Instead of waiting 6 months, we could
release around end of January, early Feb (say: branch mid Jan, release
end of Jan).

Thoughts?

Doug, you asked for a couple of weeks notice for 7.0. I'm being a little
more aggressive. Is this going to be an issue for you?

-- 
Joel

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Jack Howarth]

  Is there any chance that x86_64-apple-darwin10 could be added
to the supported targets? The current gdb cvs builds on that
target, but can't debug binaries...

http://sourceware.org/ml/gdb/2009-08/msg00270.html

This would be helpful because it is unclear how much backward
compatibility there will be from the new VTA generated debug
code in gcc 4.5 with older versions of gdb. The gdb 7.0 release
is being recommended because any hacks added to gcc to work
around bugs in previous gdb releases may not be reintroduced
in gcc-4.5 after the VTA merge.
                    Jack

On Wed, Sep 02, 2009 at 09:44:25AM -0700, Joel Brobecker wrote:
> Hello everyone,
> 
> I think everyone is anxious to see the next release out as fast as
> we can; it is going to be a major step forward compared to the previous
> releases!
> 
> First, we need to make progress on the following documented issues:
> 
>   (a) Assert in frame.c:get_frame_arch
>       Basically, we added an assertion to get_frame_arch, which should
>       always be true. But to be safe, we decided to remove it from
>       the release sources if the release branch was cut before we had
>       enough time to field-test that change.  We added that assertion
>       in January, so I think we can skip that item.  I don't think we
>       ever tripped that assertion, did we?
> 
>   (b) Rename the python-support files to be 8.3-compliant.
>       I thought that the change had been approved, but I see that
>       the change has not been made.  Has it been approved? If yes,
>       it is being held up because we don't know how to best rename
>       files without disturbing git?
> 
>   (c) varobj support for Python pretty-printing
>       Tom gave a quick status on IRC yesterday. It sounds like
>       there isn't much left to do. Perhaps a quick update on the Wiki
>       page to state exactly what's left would be nice.  Unless fixing
>       the last thing or two might be faster ;-).
> 
>   (d) PR/9711: Quadratic slowdown for "where" command.
>       Pending catastrophes, I should be able to fix that this week.
> 
>   (e) PR/9786: Typing "info frame" immediately after connecting to
>       a remote target causes an assertion error on x86 GNU/Linux (32 bit). 
>       That's a real regression.  I don't know that anyone ever looked
>       at this issue. I did reproduce the issue many moons ago. I don't
>       think it reproduces on x86_64.  Any taker?
> 
>   (f) bug in breakpoint commands: commands not evaluated outside of
>       main command loop.
>       http://sourceware.org/ml/gdb-patches/2008-07/msg00583.html
>       There is a suggested patch, but needs looking at. Any taker?
> 
> If there are any issue that you know of that are *RELEASE-CRITICAL*
> (build failure, regressions), please let us know, so we can decide
> what to do, and possibly add it to the 7.0 TODO list. Anything else,
> I suggest, should no longer be a priority for 7.0.
> 
> In terms of dates, I would like us to try to release sooner rather than
> later. Can I suggest we try to shoot for Wed Sep 9th for the branch date,
> and then try to release a couple of weeks after (that would be the 23rd)?
> 
> If there are any fixes that would be nice for the release but don't make
> it to the 23rd, we can always have a corrective 7.0.1 release mid
> December. Also, it sounds like a lot more new features are currently
> being developed, and people are trying to make it for 7.0. I propose to
> release 7.1 not too long after 7.0: Instead of waiting 6 months, we could
> release around end of January, early Feb (say: branch mid Jan, release
> end of Jan).
> 
> Thoughts?
> 
> Doug, you asked for a couple of weeks notice for 7.0. I'm being a little
> more aggressive. Is this going to be an issue for you?
> 
> -- 
> Joel

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Joel Brobecker]

> Is there any chance that x86_64-apple-darwin10 could be added
> to the supported targets? The current gdb cvs builds on that
> target, but can't debug binaries...
> 
> http://sourceware.org/ml/gdb/2009-08/msg00270.html

If we manage to follow the schedule that I proposed, I think that
the changes for this to happen are slim. For this to make it to 7.0,
you'll need to either fix it or find someone to fix it, and then
have it approved for inclusion.

Having said that, This is typically the type of fix that can be
checked in a branch - unless the change is really intrusive, that is.
The actual release date is about 3 weeks away, and I propose to also
make a corrective release in December. That gives you a little more
time to get this fixed.

-- 
Joel

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel>   (b) Rename the python-support files to be 8.3-compliant.
Joel>       I thought that the change had been approved, but I see that
Joel>       the change has not been made.  Has it been approved? If yes,
Joel>       it is being held up because we don't know how to best rename
Joel>       files without disturbing git?

I'm ok with the simple rm + add approach.  This has the advantage of not
requiring anybody to log into sourceware and monkey around with the
repository.  One thing that has factored into my thinking here is that
there have not been many revisions to these files in gdb CVS.  So,
trying to preserve the history in a super-convenient form is not
extremely important.  On the off chance that somebody needs the older
history they can just "cvs log" the old file names.

Joel>   (c) varobj support for Python pretty-printing
Joel>       Tom gave a quick status on IRC yesterday. It sounds like
Joel>       there isn't much left to do. Perhaps a quick update on the Wiki
Joel>       page to state exactly what's left would be nice.  Unless fixing
Joel>       the last thing or two might be faster ;-).

There's one more bug.  Of course, there's only been one more bug for the
last 4 weeks :-(

I plan to do the work to merge this to trunk this week.

Joel>   (f) bug in breakpoint commands: commands not evaluated outside of
Joel>       main command loop.
Joel>       http://sourceware.org/ml/gdb-patches/2008-07/msg00583.html
Joel>       There is a suggested patch, but needs looking at. Any taker?

There are a number of other unreviewed patches.  I can try to make a
list if that would be helpful.

I would like us to commit to reviewing all patches that arrived before
some cutoff date before the release.  I think this is important to
encourage continued contributions to GDB.  Also, I consider this part of
our duty as maintainers.

I don't have a proposal for when this cutoff should be, but I think it
should be in the future.  (It could be the very near future.)

Joel> If there are any issue that you know of that are *RELEASE-CRITICAL*
Joel> (build failure, regressions), please let us know

I have a couple more, I'm afraid.

I think the "Fix Darwin breakage" and "Speed up find_pc_section" threads
need to reach some sort of resolution.  I haven't caught up on these
yet, so maybe these are already concluded.

Finally, I think we should get the DW_OP_*_value patch in.  This patch
is needed with GCC svn trunk, now that VTA has gone in.  (I'm working on
the final bit of this patch: the test cases.)

Joel> In terms of dates, I would like us to try to release sooner rather than
Joel> later. Can I suggest we try to shoot for Wed Sep 9th for the branch date,
Joel> and then try to release a couple of weeks after (that would be the 23rd)?

It seems possible, at least if people step up for the remaining tasks.

Joel> Also, it sounds like a lot more new features are currently being
Joel> developed, and people are trying to make it for 7.0. I propose to
Joel> release 7.1 not too long after 7.0: Instead of waiting 6 months,
Joel> we could release around end of January, early Feb (say: branch mid
Joel> Jan, release end of Jan).

I think that would be a good idea.

Tom

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Hui Zhu]

Hi Joel,

Thanks for your work.

Gdb-cvs-head have a build error in cygwin with "--enable-targets=all
--enable-64-bits-bfd".
http://sourceware.org/ml/gdb-patches/2009-08/msg00559.html

I had post a patch for it.  It still in discussion.
http://sourceware.org/ml/gdb-patches/2009-08/msg00574.html

Thanks,
Hui

On Thu, Sep 3, 2009 at 00:44, Joel Brobecker<brobecker@adacore.com> wrote:
> Hello everyone,
>
> I think everyone is anxious to see the next release out as fast as
> we can; it is going to be a major step forward compared to the previous
> releases!
>
> First, we need to make progress on the following documented issues:
>
>  (a) Assert in frame.c:get_frame_arch
>      Basically, we added an assertion to get_frame_arch, which should
>      always be true. But to be safe, we decided to remove it from
>      the release sources if the release branch was cut before we had
>      enough time to field-test that change.  We added that assertion
>      in January, so I think we can skip that item.  I don't think we
>      ever tripped that assertion, did we?
>
>  (b) Rename the python-support files to be 8.3-compliant.
>      I thought that the change had been approved, but I see that
>      the change has not been made.  Has it been approved? If yes,
>      it is being held up because we don't know how to best rename
>      files without disturbing git?
>
>  (c) varobj support for Python pretty-printing
>      Tom gave a quick status on IRC yesterday. It sounds like
>      there isn't much left to do. Perhaps a quick update on the Wiki
>      page to state exactly what's left would be nice.  Unless fixing
>      the last thing or two might be faster ;-).
>
>  (d) PR/9711: Quadratic slowdown for "where" command.
>      Pending catastrophes, I should be able to fix that this week.
>
>  (e) PR/9786: Typing "info frame" immediately after connecting to
>      a remote target causes an assertion error on x86 GNU/Linux (32 bit).
>      That's a real regression.  I don't know that anyone ever looked
>      at this issue. I did reproduce the issue many moons ago. I don't
>      think it reproduces on x86_64.  Any taker?
>
>  (f) bug in breakpoint commands: commands not evaluated outside of
>      main command loop.
>      http://sourceware.org/ml/gdb-patches/2008-07/msg00583.html
>      There is a suggested patch, but needs looking at. Any taker?
>
> If there are any issue that you know of that are *RELEASE-CRITICAL*
> (build failure, regressions), please let us know, so we can decide
> what to do, and possibly add it to the 7.0 TODO list. Anything else,
> I suggest, should no longer be a priority for 7.0.
>
> In terms of dates, I would like us to try to release sooner rather than
> later. Can I suggest we try to shoot for Wed Sep 9th for the branch date,
> and then try to release a couple of weeks after (that would be the 23rd)?
>
> If there are any fixes that would be nice for the release but don't make
> it to the 23rd, we can always have a corrective 7.0.1 release mid
> December. Also, it sounds like a lot more new features are currently
> being developed, and people are trying to make it for 7.0. I propose to
> release 7.1 not too long after 7.0: Instead of waiting 6 months, we could
> release around end of January, early Feb (say: branch mid Jan, release
> end of Jan).
>
> Thoughts?
>
> Doug, you asked for a couple of weeks notice for 7.0. I'm being a little
> more aggressive. Is this going to be an issue for you?
>
> --
> Joel
>

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Cc: gdb@sourceware.org
> Date: Wed, 02 Sep 2009 13:26:28 -0600
> 
> There are a number of other unreviewed patches.  I can try to make a
> list if that would be helpful.

I hope the catch syscalls is one of them.  I never understood why it
wasn't committed.  (Apologies if it was and I just missed that.)

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Hui Zhu]

On Thu, Sep 3, 2009 at 11:15, Eli Zaretskii<eliz@gnu.org> wrote:
>> From: Tom Tromey <tromey@redhat.com>
>> Cc: gdb@sourceware.org
>> Date: Wed, 02 Sep 2009 13:26:28 -0600
>>
>> There are a number of other unreviewed patches.  I can try to make a
>> list if that would be helpful.
>
> I hope the catch syscalls is one of them.  I never understood why it
> wasn't committed.  (Apologies if it was and I just missed that.)
>

Agree.  And I didn't see the mail from Sérgio in a lot of months.
Maybe we need some help from other people in IBM.

Thanks,
Hui

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Doug Evans]

On Wed, Sep 2, 2009 at 9:44 AM, Joel Brobecker<brobecker@adacore.com> wrote:
>
> Doug, you asked for a couple of weeks notice for 7.0. I'm being a little
> more aggressive. Is this going to be an issue for you?

Nope, fine with me.

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Tristan Gingold]

On Sep 2, 2009, at 7:09 PM, Jack Howarth wrote:

>  Is there any chance that x86_64-apple-darwin10 could be added
> to the supported targets? The current gdb cvs builds on that
> target, but can't debug binaries...

Feel free to investigate or work on it.  We have just ordered Snow  
Leopard so I won't look at this before
a few days.

Tristan.

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Paul Pluzhnikov]

On Wed, Sep 2, 2009 at 9:44 AM, Joel Brobecker<brobecker@adacore.com> wrote:

> If there are any issue that you know of that are *RELEASE-CRITICAL*
> (build failure, regressions), please let us know, so we can decide
> what to do, and possibly add it to the 7.0 TODO list.

I think elimination of failing asserts:
  http://sourceware.org/ml/gdb-patches/2009-09/msg00062.html
should be considered release blocking.

I am hoping for a quick review :-)
-- 
Paul Pluzhnikov

RE: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Pierre Muller]

 I second this one,
I came across these assertions while trying to debug
gdb with itself on OpenSolaris!
  The offending section where
 something  .SUNW_xxx special sections

  But this means that I was unable to use 
current CVS gdb on i386 OpenSolaris :(

Pierre Muller

> -----Message d'origine-----
> De : gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] De la
> part de Paul Pluzhnikov
> Envoyé : Thursday, September 03, 2009 5:54 PM
> À : Joel Brobecker
> Cc : gdb@sourceware.org
> Objet : Re: [gdb-7.0 release] 2009-09-02 status and proposed plan
> 
> On Wed, Sep 2, 2009 at 9:44 AM, Joel Brobecker<brobecker@adacore.com>
> wrote:
> 
> > If there are any issue that you know of that are *RELEASE-CRITICAL*
> > (build failure, regressions), please let us know, so we can decide
> > what to do, and possibly add it to the 7.0 TODO list.
> 
> I think elimination of failing asserts:
>   http://sourceware.org/ml/gdb-patches/2009-09/msg00062.html
> should be considered release blocking.
> 
> I am hoping for a quick review :-)
> --
> Paul Pluzhnikov

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Paul Pluzhnikov]

On Thu, Sep 3, 2009 at 8:59 AM, Pierre Muller<muller@ics.u-strasbg.fr> wrote:

> I came across these assertions while trying to debug
> gdb with itself on OpenSolaris!
>  The offending section where
>  something  .SUNW_xxx special sections
>
>  But this means that I was unable to use
> current CVS gdb on i386 OpenSolaris :(

Could you check whether this patch:
 http://sourceware.org/ml/gdb-patches/2009-08/msg00437.html
fixes it on OpenSolaris/i386?

Thanks,
-- 
Paul Pluzhnikov

RE: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Anirban Sinha]

>
>I think everyone is anxious to see the next release out as fast as
>we can; it is going to be a major step forward compared to the previous
>releases!

You bet! We are among those who are waiting for the next release...
patiently :)


>
>If there are any fixes that would be nice for the release but don't
make
>it to the 23rd, we can always have a corrective 7.0.1 release mid
>December. Also, it sounds like a lot more new features are currently
>being developed, and people are trying to make it for 7.0. I propose to
>release 7.1 not too long after 7.0: Instead of waiting 6 months, we
>could
>release around end of January, early Feb (say: branch mid Jan, release
>end of Jan).
>
>Thoughts?

Sounds very reasonable. Great work guys!

Cheers,
Ani

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Joel Brobecker]

> Joel>   (b) Rename the python-support files to be 8.3-compliant.
[...]
> I'm ok with the simple rm + add approach.

I agree. Let's apply the patch ASAP. Do you happen to have a rebased
version of the patch somewhere in archer, by any chance? Otherwise,
I'll try to contact Thiago to get the latest version and work from
there.

> There are a number of other unreviewed patches.  I can try to make a
> list if that would be helpful.

I think it would. We need to draw our attention to everything that
needs to be done before branching.

> I would like us to commit to reviewing all patches that arrived before
> some cutoff date before the release.  I think this is important to
> encourage continued contributions to GDB.  Also, I consider this part
> of our duty as maintainers.

I would agree with that, but it means that we need to firmly commit
to the release. I'm available, but if it's just two or three of us,
this is just going to be too much work. I understand that someone
might be disappointed that his patch does not make the next release,
but should we really delay this further for things like minor enhancements
for instance?

I propose the following approach: Let's commit to reviewing promptly
all patches that are posted before branch time. Patches that are safe
for the branch will be added and part of the 7.0.1 release.  Others
should not be checked in at such a late stage anyway (IMO).  What do
you think?

> I think the "Fix Darwin breakage" and "Speed up find_pc_section" threads
> need to reach some sort of resolution.  I haven't caught up on these
> yet, so maybe these are already concluded.

OK - I added these two to the wiki page. I have completely zapped most
threads while I was away. Would you mind posting URLs to these
discussions for me?

> Finally, I think we should get the DW_OP_*_value patch in.  This patch
> is needed with GCC svn trunk, now that VTA has gone in.  (I'm working on
> the final bit of this patch: the test cases.)

I see that you posted the patch (as an RFC. I will take a look, although
I'm not very familiar with this area). Perhaps we could coerce Daniel
to give his opinion on this?

> It seems possible, at least if people step up for the remaining tasks.

Yeah, that's the problem. On the couple of issues that I pointed out,
no one really stepped up to the plate :-(. I'll take a look at frame
assertion failure with gdbserver, but it'd be nice to get some help
fixing the rest.

-- 
Joel

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Joel Brobecker]

> I hope the catch syscalls is one of them.  I never understood why it
> wasn't committed.  (Apologies if it was and I just missed that.)

I also hope that this patch makes it to the release, but I do not see
this new feature as release critical. So, unless other GMs would prefer
to have it for 7.0, I personally think that we should not delay the
release just for this feature.

-- 
Joel

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Joel Brobecker]

> Gdb-cvs-head have a build error in cygwin with "--enable-targets=all
> --enable-64-bits-bfd".
> http://sourceware.org/ml/gdb-patches/2009-08/msg00559.html

Thanks for letting us know.  I've added this item to the 7.0 checklist.

-- 
Joel

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Joel Brobecker]

> I think elimination of failing asserts:
>   http://sourceware.org/ml/gdb-patches/2009-09/msg00062.html
> should be considered release blocking.

Agreed. (and thanks!)

I think this is part of the "speed up find_pc_section" thread that
Tom mentioned, so I added the link there in our 7.0 checklist.

-- 
Joel

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Eli> I hope the catch syscalls is one of them.  I never understood why it
Eli> wasn't committed.  (Apologies if it was and I just missed that.)

Joel> I also hope that this patch makes it to the release, but I do not see
Joel> this new feature as release critical. So, unless other GMs would prefer
Joel> to have it for 7.0, I personally think that we should not delay the
Joel> release just for this feature.

I am unhappy with the facts of the situation: we've had a nice new
feature, rewritten several times, pending since April.  I know both from
personal experience, and from talking to contributors, that this sort of
thing is very demoralizing, and consequently hurts GDB.

That said, I do agree with your reasoning and conclusion.

Tom

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Tom> I'm ok with the simple rm + add approach.

Joel> I agree. Let's apply the patch ASAP. Do you happen to have a
Joel> rebased version of the patch somewhere in archer, by any chance?

No, I'm afraid not.

Tom> There are a number of other unreviewed patches.  I can try to make a
Tom> list if that would be helpful.

Joel> I think it would. We need to draw our attention to everything that
Joel> needs to be done before branching.

My list is probably incomplete, since I have not been systematic about
tracking patches.  That said, patch submitters do bear some burden to
ping their patches and to otherwise irritate a maintainer into
responding ;)

* The catch syscall patches.  I didn't dig up the URLs for these.

* Caz Yokoyama's kgdb patch.  I don't think the most recent one was ever
  reviewed.
  http://permalink.gmane.org/gmane.comp.gdb.patches/50989

* Watchpoint on an unloaded shared library
  http://permalink.gmane.org/gmane.comp.gdb.patches/46187
  http://permalink.gmane.org/gmane.comp.gdb.patches/46290

* gdb.objc/objcdecode.exp test error
  http://permalink.gmane.org/gmane.comp.gdb.patches/47073

* Xtensa backtrace
  http://permalink.gmane.org/gmane.comp.gdb.patches/48614

* Fix breakpoints when several source files have the same name
  http://permalink.gmane.org/gmane.comp.gdb.patches/49047

* Jonas Maebe's calling convention patch, pinged twice.
  http://permalink.gmane.org/gmane.comp.gdb.patches/49467

* Nathan Froyd's internal error patch, pinged once.
  http://permalink.gmane.org/gmane.comp.gdb.patches/50458

* Paul Pluzhnikov's pending patches.
  He pinged these recently:
  http://sourceware.org/ml/gdb-patches/2009-08/msg00372.html
  http://sourceware.org/ml/gdb-patches/2009-08/msg00437.html

* Jan Kratochvil's watchpoint series.
  First one: http://permalink.gmane.org/gmane.comp.gdb.patches/51128

* Sami Wagiaalla's namespace patches.
  http://permalink.gmane.org/gmane.comp.gdb.patches/51166
  http://permalink.gmane.org/gmane.comp.gdb.patches/51167

* Use external editor in 'commands' command
  http://permalink.gmane.org/gmane.comp.gdb.patches/51394

* Keith's recent dwarf2/c++ patches.

There are a couple other biggish pending things I remember: Vala and D
support, but those are stalled for some reason on the submitter side
(lack of activity or waiting for paperwork).

I've meant to review some of these, but of course it is tough to get to
them all.  And, there are several in here that I won't review as I don't
have the necessary expertise.  I'm not sure whether any of these require
paperwork, either.

Joel> I understand that someone might be disappointed that his patch
Joel> does not make the next release, but should we really delay this
Joel> further for things like minor enhancements for instance?

I just wanted to encourage maintainers to make an extra effort.
I agree we shouldn't delay the release for anything minor.

Joel> I propose the following approach: Let's commit to reviewing promptly
Joel> all patches that are posted before branch time. Patches that are safe
Joel> for the branch will be added and part of the 7.0.1 release.  Others
Joel> should not be checked in at such a late stage anyway (IMO).  What do
Joel> you think?

Yes, sounds good to me.

Tom

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Matt Rice]

On Thu, Sep 3, 2009 at 1:11 PM, Tom Tromey<tromey@redhat.com> wrote:

<snip>

> * gdb.objc/objcdecode.exp test error
>  http://permalink.gmane.org/gmane.comp.gdb.patches/47073
>

sorry i've dropped the ball on this one.
still got to get my copright assignment in,

if i recall correctly all of my attempts to actually fix the problems
have been foiled by something or another,

they fix the bug in some situations but miss in others.

so probably the only thing applicable from those would be the new
tests i've added, i'll try to get back to this for the next go around.

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Joel Brobecker]

> I am unhappy with the facts of the situation: we've had a nice new
> feature, rewritten several times, pending since April.  I know both from
> personal experience, and from talking to contributors, that this sort of
> thing is very demoralizing, and consequently hurts GDB.

I definitely share your feeling.

We should try to find ways to reduce the risk of this happening again,
and in the meantime let's try to be responsive to his patches. Have
the patches been sitting unreviewed since April?

-- 
Joel

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Joel Brobecker]

> My list is probably incomplete, since I have not been systematic about
> tracking patches.  That said, patch submitters do bear some burden to
> ping their patches and to otherwise irritate a maintainer into
> responding ;)

Right :). Patch submitters, if you have a patch that has not been
reviewed yet, would you mind sending me a *private* email with
a URL to the patch, please? I will add it to our checklist. We can
try to review it promptly.

> I've meant to review some of these, but of course it is tough to get to
> them all.  And, there are several in here that I won't review as I don't
> have the necessary expertise.

Same here. Anything that says C++ usually scares me away. But I'll
start taking the stance that, if no one liked at it for weeks, and
I don't see anything wrong, let's put it in, and see what happens.
I would have prefered we did that at some other time but close to
a release, though...

> I just wanted to encourage maintainers to make an extra effort.

And let's encourage more people to become maintainers if we think
they are ready.

I've added a new section to the gdb-7.0_release wiki page, that
lists all patches that we know of that we should make every effort
to review before the 7.0 release is made.

-- 
Joel

RE: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Pierre Muller]

  Hi Paul,

  I checked your patch and it does solve the problem.
Instead of a internal_error, I get a warning 
about .SUNW_version and .SUNW_versym sections
between intertwined.


Pierre Muller
Pascal language support maintainer for GDB


> -----Message d'origine-----
> De : gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] De la
> part de Paul Pluzhnikov
> Envoyé : Thursday, September 03, 2009 6:11 PM
> À : Pierre Muller
> Cc : Joel Brobecker; gdb@sourceware.org
> Objet : Re: [gdb-7.0 release] 2009-09-02 status and proposed plan
> 
> On Thu, Sep 3, 2009 at 8:59 AM, Pierre Muller<muller@ics.u-strasbg.fr>
> wrote:
> 
> > I came across these assertions while trying to debug
> > gdb with itself on OpenSolaris!
> >  The offending section where
> >  something  .SUNW_xxx special sections
> >
> >  But this means that I was unable to use
> > current CVS gdb on i386 OpenSolaris :(
> 
> Could you check whether this patch:
>  http://sourceware.org/ml/gdb-patches/2009-08/msg00437.html
> fixes it on OpenSolaris/i386?
> 
> Thanks,
> --
> Paul Pluzhnikov

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Paul Pluzhnikov]

On Fri, Sep 4, 2009 at 3:19 AM, Pierre Muller<muller@ics.u-strasbg.fr> wrote:

>  I checked your patch and it does solve the problem.
> Instead of a internal_error, I get a warning
> about .SUNW_version and .SUNW_versym sections
> between intertwined.

Thanks Pierre.

Could you please post output from
  readelf -S <objfile-mentioned-in-warning>

That should help understanding why there is overlap in the first place.

Thanks,
-- 
Paul Pluzhnikov

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Paul Pluzhnikov]

On Thu, Sep 3, 2009 at 8:54 AM, Paul Pluzhnikov<ppluzhnikov@google.com> wrote:

> I think elimination of failing asserts:
>  http://sourceware.org/ml/gdb-patches/2009-09/msg00062.html
> should be considered release blocking.

I think there is another release blocker:

For the last two weeks we've been running with a beta release built on
20090824 from CVS Head, and have several (more than 20) reports of
SIGSGV in GDB, when restarting the inferior.

Yesterday I got a repro and analyzed it. AFAICT, the problem is that
in (recently added) clean_up_objfile_types, we make copies of types
from unloaded solibs.

Names of these types come from the .debug_info of the corresponding solib.

If solib is small, its .debug_info is obstack_alloc()ed and still
valid at the time of clean_up_objfile_types call.
If it is large, it gets bfd_mmap()ed in dwarf2_read_section(), and is
munmapped in dwarf2_per_objfile_cleanup, which executes *before*
clean_up_objfile_types. By the time we come to strdup in
copy_type_recursive (called from clean_up_objfile_types), the name of
the type has been munmapped.

Here is the crash stack (sorry about gmail line wrapping):

#0  0x00007f0c16a60a30 in strlen () from /usr/lib64/libc.so.6
#1  0x000000000062f896 in xstrdup (s=0x7f0c0ef9ce64 <Address
0x7f0c0ef9ce64 out of bounds>) at
../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/libiberty/xstrdup.c:33
#2  0x00000000004e5769 in copy_type_recursive (objfile=<value
optimized out>, type=0x17f2a3b8, copied_types=0x17ec8f60)
   at ../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/gdb/gdbtypes.c:2877
#3  0x000000000047200b in clean_up_objfile_types (objfile=0x8903b80,
datum=<value optimized out>)
   at ../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/gdb/python/python-type.c:548
#4  0x000000000040300b in clear_objfile_data (objfile=0x8903b80) at
../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/gdb/objfiles.c:1036
#5  0x0000000000403a56 in objfile_free_data (objfile=0x8903b80) at
../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/gdb/objfiles.c:1019
#6  free_objfile (objfile=0x8903b80) at
../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/gdb/objfiles.c:453
#7  0x0000000000403bec in objfile_purge_solibs () at
../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/gdb/objfiles.c:758
#8  0x00000000004f0545 in target_pre_inferior (from_tty=0) at
../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/gdb/target.c:1897
#9  0x00000000004c1b4c in run_command_1 (args=0x0, from_tty=0,
tbreak_at_main=0) at
../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/gdb/infcmd.c:482

The 0x7f0c0ef9ce64 used to point to "int32" in a DWARF2 section which
has since been removed/unmapped.

I am still working on a stand-alone repro case.

-- 
Paul Pluzhnikov

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Doug Evans]

On Thu, Sep 3, 2009 at 12:25 PM, Joel Brobecker<brobecker@adacore.com> wrote:
>
>> There are a number of other unreviewed patches.  I can try to make a
>> list if that would be helpful.
>
> I think it would. We need to draw our attention to everything that
> needs to be done before branching.

I think it would too.

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> We should try to find ways to reduce the risk of this happening again,
Joel> and in the meantime let's try to be responsive to his patches. Have
Joel> the patches been sitting unreviewed since April?

Yeah, I think the "try 5" series was the last posted:

http://sourceware.org/ml/gdb-patches/2009-04/msg00625.html

Looking again, there are some follow-ups.

I asked Sergio on irc and he said he's going to resubmit ASAP.

Tom

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Sérgio Durigan Júnior]

Hello Hui and Eli,

On Thursday 03 September 2009, Hui Zhu wrote:
> On Thu, Sep 3, 2009 at 11:15, Eli Zaretskii<eliz@gnu.org> wrote:
> >> From: Tom Tromey <tromey@redhat.com>
> >> Cc: gdb@sourceware.org
> >> Date: Wed, 02 Sep 2009 13:26:28 -0600
> >>
> >> There are a number of other unreviewed patches.  I can try to make a
> >> list if that would be helpful.
> >
> > I hope the catch syscalls is one of them.  I never understood why it
> > wasn't committed.  (Apologies if it was and I just missed that.)
>
> Agree.  And I didn't see the mail from Sérgio in a lot of months.
> Maybe we need some help from other people in IBM.

I am preparing my sixth version of this patch :-).  I found an strange bug 
(and already fixed it), but didn't have time to prepare the patch for 
resubmission yet.  I intend to do so today.

Thank you for remembering the catch syscall :-).

Regards,

-- 
Sérgio Durigan Júnior
Linux on Power Toolchain - Software Engineer
Linux Technology Center - LTC
IBM Brazil

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Paul Pluzhnikov]

On Fri, Sep 4, 2009 at 8:25 AM, Paul Pluzhnikov<ppluzhnikov@google.com> wrote:

> I am still working on a stand-alone repro case.

Here it is:

--- cut --- foo.cc ---
#include <stdio.h>

#define X6(a) a,a,a,a,a,a
#define R8(a) a##a##a##a##a##a##a##a##a

#define Foo R8(Fee_Fi_Fo_Fum_I_smell_the_blood_of_an_Englishman)
#define Bar R8(Bar)

template <class P, class Q, class R, class S, class T, class U>
struct Foo { Foo(); };

template <class P, class Q, class R, class S, class T, class U>
Foo<P, Q, R, S, T, U>::Foo()
{
  printf ("In %s\n", __func__);
}

struct Bar { };

typedef Foo<X6(Bar)> FooBar1;
typedef Foo<X6(FooBar1)> FooBar2;
typedef Foo<X6(FooBar2)> FooBar3;
typedef Foo<X6(FooBar3)> FooBar4;
typedef Foo<X6(FooBar4)> FooBar5;

struct Zork { int x; };

int fn(int *ip)
{
  FooBar1 f1;
  FooBar2 f2;
  FooBar3 f3;
  FooBar4 f4;
  FooBar5 f5;

  Zork z;
  z.x = ip[0]; // crash
  return z.x;
}
--- cut --- foo.cc ---

--- cut --- main.cc ---
int fn(int *);
int main() { return fn(0); }
--- cut --- main.cc ---

g++ -g -fPIC -shared foo.cc -o foo.so && g++ -g main.cc ./foo.so

gdb64-cvs ./a.out
GNU gdb (GDB) 6.8.50.20090904-cvs
...
Reading symbols from /usr/local/google/tmp/gdb-crash/a.out...done.
(gdb) run
In Fee_Fi_Fo_Fum_I_smell...

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7bdf1d9 in fn (ip=0x0) at foo.cc:37
37	  z.x = ip[0]; // crash

(gdb) py x = gdb.lookup_type('Zork')
(gdb) run
Segmentation fault (core dumped)

I will not be able to work on a fix before next Tuesday, so if anybody
fixes this before then, please let me know.

Thanks,
-- 
Paul Pluzhnikov

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Doug Evans]

On Fri, Sep 4, 2009 at 10:59 AM, Paul Pluzhnikov<ppluzhnikov@google.com> wrote:
> On Fri, Sep 4, 2009 at 8:25 AM, Paul Pluzhnikov<ppluzhnikov@google.com> wrote:
>
>> I am still working on a stand-alone repro case.
>
> Here it is:
>
>[...]
> Segmentation fault (core dumped)
>
> I will not be able to work on a fix before next Tuesday, so if anybody
> fixes this before then, please let me know.
>
> Thanks,
> --
> Paul Pluzhnikov
>

I'll look into it.

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Sérgio Durigan Júnior]

Hi Tom,

On Friday 04 September 2009, Tom Tromey wrote:
> I asked Sergio on irc and he said he's going to resubmit ASAP.

Already did :-).  It's officially the "try 6" now!

Regards,

-- 
Sérgio Durigan Júnior
Linux on Power Toolchain - Software Engineer
Linux Technology Center - LTC
IBM Brazil

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Sérgio Durigan Júnior]

Hi Joel,

On Thursday 03 September 2009, Joel Brobecker wrote:
> I also hope that this patch makes it to the release, but I do not see
> this new feature as release critical. So, unless other GMs would prefer
> to have it for 7.0, I personally think that we should not delay the
> release just for this feature.

I agree.  GDB 7.0 release shouldn't be delayed because of this single feature.

-- 
Sérgio Durigan Júnior
Linux on Power Toolchain - Software Engineer
Linux Technology Center - LTC
IBM Brazil

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Sérgio Durigan Júnior]

Hi Tom,

On Thursday 03 September 2009, Tom Tromey wrote:
> I am unhappy with the facts of the situation: we've had a nice new
> feature, rewritten several times, pending since April.  I know both from
> personal experience, and from talking to contributors, that this sort of
> thing is very demoralizing, and consequently hurts GDB.

Thank you very much for this.  When I first sent this patch, I expected it to 
be accepted very fast, since it's a "wanted feature".  However, and I *really* 
understand the reasons, it has became an "snow ball" and still waiting for 
review now.  Anyway, I won't stop until it gets accepted :-).

Regards,

-- 
Sérgio Durigan Júnior
Linux on Power Toolchain - Software Engineer
Linux Technology Center - LTC
IBM Brazil

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 525 bytes --]

> In terms of dates [...]

I just committed the attached patch to the GDB schedule page. It now
shows target dates for 7.0 and 7.1.

One thing I should mention that I didn't talk about is the pre-release.
I've set the date of the pre-release the day after the branch is cut.
Given how careful we are in cleaning up HEAD before taking the branch,
I figured there is no point in waiting before cutting the first pre-
release. The sooner we create that pre-release, the more chances we
have of people giving it a try.

-- 
Joel

[-- Attachment #2: schedule.diff --]
[-- Type: text/x-diff, Size: 1896 bytes --]

Index: schedule/index.html
===================================================================
RCS file: /cvs/gdb/htdocs/schedule/index.html,v
retrieving revision 1.40
diff -u -p -r1.40 index.html
--- schedule/index.html	6 Feb 2009 01:07:05 -0000	1.40
+++ schedule/index.html	4 Sep 2009 23:01:24 -0000
@@ -51,19 +51,19 @@ Fish]" /></a>
 
 <center>
 <table>
-<tr><td></td><th>CURRENT (6.8)</th><th>NEXT (7.0)</th>
+<tr><td></td><th>CURRENT (7.0)</th><th>NEXT (7.1)</th>
 </tr>
 <tr>
-<th>Branch:</th><td>February (2008-02-05)</td><td>May (2009-05-08)</td>
+<th>Branch:</th><td>September (2009-09-09)</td><td>January (2010-01-20)</td>
 </tr>
 <tr>
-<th>Pre-release:</th><td>February (2008-02-19)</td><td>May (2009-05-22)</td>
+<th>Pre-release:</th><td>September (2009-09-10)</td><td>January (2010-01-11)</td>
 </tr>
 <tr>
-<th>Release:</th><td>March (2008-03-04)</td><td>June (2009-06-05)</td>
+<th>Release:</th><td>September (2009-09-23)</td><td>February (2010-02-03)</td>
 </tr>
 <tr>
-<th>reSpin:</th><td>N/A</td><td>September (2009-09-04)</td>
+<th>reSpin:</th><td>December (2009-12-17)</td><td>To Be Determined</td>
 </tr>
 </table>
 </center>
@@ -84,7 +84,9 @@ equivalent amount.
 <tr> <th>Release</th><th>Estimate</th><th>Schedule</th><th>Actual</th><th>Slip (months)</th><th align=left>Comment</th></tr>
 
 <tr>
-<td>6.8</td><td>2008-02</td><td>2008-02</td><td>2007-02-29</td>
+<td>7.0</td><td>2009-05</td><td>2009-05</td><td></td>
+  <td align=center></td><td align=left></td> </tr>
+<td>6.8</td><td>2008-02</td><td>2008-02</td><td>2008-02-29</td>
   <td align=center>0</td><td align=left></td> </tr>
 
 <tr>
@@ -199,7 +201,7 @@ Floor, Boston, MA 02110-1301 USA.</p>
 <p>Verbatim copying and distribution of this entire article is
 permitted in any medium, provided this notice is preserved.</p>
 
-<p>Last modified 2009-02-05.</p>
+<p>Last modified 2009-09-04.</p>
 </address>
 
 </body>

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

Hui,

> I had post a patch for it.  It still in discussion.
> http://sourceware.org/ml/gdb-patches/2009-08/msg00574.html

As far as I can tell, you received some feedback from one of the
maintainers (Mark Kettenis) about your patch:

    http://sourceware.org/ml/gdb-patches/2009-08/msg00584.html

I also looked at your patch before looking at the replies, and I had
the same comments as Jiang and Mark. The casts in this raised a red
flag, and I don't see why we should need them.

Would it make sense to define a type syscall_t that's either an int
or an unsigned int, and use that consistently throughout?  Otherwise,
another simpler option would be to just use either int or unsigned int
without using a typedef.

In the meantime, I think you can get away from this all by using
regcache_raw_write_signed. Read the syscall ID as a signed number,
all should be fine. I'm attaching a patch that fixes the build
issue an illustrates this suggestion. Can you please give it a
test and resubmit if it works for you?

-- 
Joel

[-- Attachment #2: syscall-cygwin-64bit.diff --]
[-- Type: text/x-diff, Size: 1184 bytes --]

Index: i386-linux-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-linux-tdep.c,v
retrieving revision 1.66
diff -u -p -r1.66 i386-linux-tdep.c
--- i386-linux-tdep.c	10 Aug 2009 03:04:44 -0000	1.66
+++ i386-linux-tdep.c	5 Sep 2009 00:24:25 -0000
@@ -367,18 +367,19 @@ static int
 i386_linux_intx80_sysenter_record (struct regcache *regcache)
 {
   int ret;
-  uint32_t tmpu32;
+  LONGEST syscall_num;
 
-  regcache_raw_read (regcache, I386_EAX_REGNUM, (gdb_byte *) &tmpu32);
+  regcache_raw_read_signed (regcache, I386_EAX_REGNUM, &syscall_num);
 
-  if (tmpu32 > 499)
+  if (syscall_num > 499)
     {
-      printf_unfiltered (_("Process record and replay target doesn't "
-                           "support syscall number %u\n"), tmpu32);
+      printf_unfiltered (_("Process record and replay target does not "
+                           "support syscall number %s\n"),
+                         plongest (syscall_num));
       return -1;
     }
 
-  ret = record_linux_system_call (tmpu32, regcache,
+  ret = record_linux_system_call (syscall_num, regcache,
 				  &i386_linux_record_tdep);
   if (ret)
     return ret;

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Joel Brobecker]

> I'll look into it.

thanks for doing this, btw. In the meantime, I've added this to
the list of things to fix...

-- 
Joel

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Mark Kettenis]

> Date: Fri, 4 Sep 2009 17:25:20 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> 
> Hui,
> 
> > I had post a patch for it.  It still in discussion.
> > http://sourceware.org/ml/gdb-patches/2009-08/msg00574.html
> 
> As far as I can tell, you received some feedback from one of the
> maintainers (Mark Kettenis) about your patch:
> 
>     http://sourceware.org/ml/gdb-patches/2009-08/msg00584.html
> 
> I also looked at your patch before looking at the replies, and I had
> the same comments as Jiang and Mark. The casts in this raised a red
> flag, and I don't see why we should need them.
> 
> Would it make sense to define a type syscall_t that's either an int
> or an unsigned int, and use that consistently throughout?  Otherwise,
> another simpler option would be to just use either int or unsigned int
> without using a typedef.

I'm not a big fan of typedefs like this.  They hide the signedness of
the type, which makes it more likely we'll end up with signed ->
unsigned conversions again or messed up range checks.

Unless people are aware of an operating system that uses negative
numbers for system calls, I don't think it matters very much whether
we use a signed or an unsigned type.  However, we have to pick one and
use it consistently.  We fail to do that for line numbers, and as a
result we still have bugs in our code.

> In the meantime, I think you can get away from this all by using
> regcache_raw_write_signed. Read the syscall ID as a signed number,
> all should be fine. I'm attaching a patch that fixes the build
> issue an illustrates this suggestion. Can you please give it a
> test and resubmit if it works for you?

This would be almost ok, but you'll need a check that syscall_num
isn't < 0 as well.

> --GvXjxJ+pjyke8COw
> Content-Type: text/x-diff; charset=us-ascii
> Content-Disposition: attachment; filename="syscall-cygwin-64bit.diff"
> 
> Index: i386-linux-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/i386-linux-tdep.c,v
> retrieving revision 1.66
> diff -u -p -r1.66 i386-linux-tdep.c
> --- i386-linux-tdep.c	10 Aug 2009 03:04:44 -0000	1.66
> +++ i386-linux-tdep.c	5 Sep 2009 00:24:25 -0000
> @@ -367,18 +367,19 @@ static int
>  i386_linux_intx80_sysenter_record (struct regcache *regcache)
>  {
>    int ret;
> -  uint32_t tmpu32;
> +  LONGEST syscall_num;
>  
> -  regcache_raw_read (regcache, I386_EAX_REGNUM, (gdb_byte *) &tmpu32);
> +  regcache_raw_read_signed (regcache, I386_EAX_REGNUM, &syscall_num);
>  
> -  if (tmpu32 > 499)
> +  if (syscall_num > 499)
>      {
> -      printf_unfiltered (_("Process record and replay target doesn't "
> -                           "support syscall number %u\n"), tmpu32);
> +      printf_unfiltered (_("Process record and replay target does not "
> +                           "support syscall number %s\n"),
> +                         plongest (syscall_num));
>        return -1;
>      }
>  
> -  ret = record_linux_system_call (tmpu32, regcache,
> +  ret = record_linux_system_call (syscall_num, regcache,
>  				  &i386_linux_record_tdep);
>    if (ret)
>      return ret;
> 
> --GvXjxJ+pjyke8COw--
> 

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Jonas Maebe]

On 05 Sep 2009, at 10:12, Mark Kettenis wrote:

> Unless people are aware of an operating system that uses negative
> numbers for system calls

Afaik, Mac OS X uses negative numbers for Mach traps and positive ones  
for BSD-style syscalls (both use the same kernel interface, i.e., int  
0x80/syscall/sysenter on x86, etc).

On the other hand, the syscall interface (both Mach and BSD) is  
private on Mac OS X and syscall behaviour can differ even between  
minor OS revisions, so a syscall replay mechanism would not be really  
feasible for that platform (or at the very least, it would be  
extremely fragile).


Jonas

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Eli Zaretskii]

> Date: Sat, 5 Sep 2009 10:12:53 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: teawater@gmail.com, gdb@sourceware.org, msnyder@vmware.com
> 
> Unless people are aware of an operating system that uses negative
> numbers for system calls, I don't think it matters very much whether
> we use a signed or an unsigned type.

If it doesn't matter, I'd prefer an unsigned type.

RE: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Pierre Muller]

Here it is (sorry for the delay):
muller@osol09:/usr/local/src/gdbcvs/build/gdb$ readelf -S /usr/lib/ld.so.1
There are 32 section headers, starting at offset 0x4613c:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk
Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0
0  0
  [ 1] .SUNW_syminfo     VERDEF          000000d4 0000d4 000290 04  AI  4
14  4
  [ 2] .hash             HASH            00000364 000364 000524 04   A  4
0  4
  [ 3] .SUNW_ldynsym     LOOS+ffffff3    00000888 000888 0023b0 10   A  5
23b  4
  [ 4] .dynsym           DYNSYM          00002c38 002c38 000a40 10   A  5
1  4
  [ 5] .dynstr           STRTAB          00003678 003678 0020b3 00  AS  0
0  1
  [ 6] .SUNW_version     VERNEED         0000572c 00572c 000060 01   A  5
3  4
  [ 7] .SUNW_version     VERDEF          0000578c 00578c 000038 01   A  5
2  4
  [ 8] .SUNW_versym      VERSYM          000057c4 0057c4 000148 02   A  4
0  4
  [ 9] .SUNW_dynsymsort  LOOS+ffffff1    0000590c 00590c 000758 04   A  3
0  4
  [10] .SUNW_reloc       REL             00006064 006064 0008c8 08   A  4
0  4
  [11] .rel.plt          REL             0000692c 00692c 000320 08  AI  4
c  4
  [12] .plt              PROGBITS        00006c4c 006c4c 000650 10  AX  0
0  4
  [13] .text             PROGBITS        000072a0 0072a0 020f5b 00  AX  0
0 16
  [14] .init             PROGBITS        00028200 028200 000013 00  AX  0
0 16
  [15] .fini             PROGBITS        00028220 028220 000013 00  AX  0
0 16
  [16] .rodata           PROGBITS        00028238 028238 004340 00   A  0
0  8
  [17] .rodata1          PROGBITS        0002c578 02c578 0005ba 00   A  0
0  4
  [18] .data             PROGBITS        0003d000 02d000 0007b3 00  WA  0
0 4096
  [19] .got              PROGBITS        0003d7b4 02d7b4 0002f8 04  WA  0
0  4
  [20] .dynamic          DYNAMIC         0003daac 02daac 0001b0 08  WA  5
0  4
  [21] .bssf             PROGBITS        0003dc5c 02dc5c 000000 00  WA  0
0  1
  [22] .picdata          PROGBITS        0003dc60 02dc60 000860 00  WA  0
0  8
  [23] .bss              NOBITS          0003e4c0 02e4c0 00138c 00  WA  0
0  8
  [24] .note             NOTE            00000000 02e4c0 00002e 01      0
0  4
  [25] .symtab           SYMTAB          00000000 02e4f0 003cd0 10     26
32a  4
  [26] .strtab           STRTAB          00000000 0321c0 00231d 00   S  0
0  1
  [27] .comment          PROGBITS        00000000 0344dd 000027 00      0
0  1
  [28] .compcom          PROGBITS        00000000 034508 00c0a6 00      0
0  8
  [29] .shstrtab         STRTAB          00000000 0405ae 000130 00   S  0
0  1
  [30] .SUNW_signature   LOOS+ffffff6    00000000 0406de 00010e 00   p  0
0  1
  [31] .SUNW_ctf         PROGBITS        00000000 040808 005931 00     25
0  4
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)
Segmentation Fault (core dumped)


Maybe the problem comes from the fact that there are two .SUNW_version
sections with
different types?
The segmentation fault is also not very pleasant...

Pierre Muller
Pascal language support maintainer for GDB



> -----Message d'origine-----
> De : Paul Pluzhnikov [mailto:ppluzhnikov@google.com]
> Envoyé : Friday, September 04, 2009 5:07 PM
> À : Pierre Muller
> Cc : Joel Brobecker; gdb@sourceware.org
> Objet : Re: [gdb-7.0 release] 2009-09-02 status and proposed plan
> 
> On Fri, Sep 4, 2009 at 3:19 AM, Pierre Muller<muller@ics.u-strasbg.fr>
> wrote:
> 
> >  I checked your patch and it does solve the problem.
> > Instead of a internal_error, I get a warning
> > about .SUNW_version and .SUNW_versym sections
> > between intertwined.
> 
> Thanks Pierre.
> 
> Could you please post output from
>   readelf -S <objfile-mentioned-in-warning>
> 
> That should help understanding why there is overlap in the first place.
> 
> Thanks,
> --
> Paul Pluzhnikov

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Paul Pluzhnikov]

Back on gdb@ list.

On Tue, Sep 8, 2009 at 9:12 AM, Pierre Muller<muller@ics.u-strasbg.fr> wrote:
>
>
>> -----Message d'origine-----
>> De : Paul Pluzhnikov [mailto:ppluzhnikov@google.com]
>> Envoyé : Tuesday, September 08, 2009 6:37 AM
>> À : Pierre Muller
>> Objet : Re: [gdb-7.0 release] 2009-09-02 status and proposed plan
>>
>> Off-list.
>>
>> On Mon, Sep 7, 2009 at 7:56 AM, Pierre Muller<muller@ics.u-strasbg.fr>
>> wrote:
>>
>> >  [ 6] .SUNW_version VERNEED  0000572c 00572c 000060 01   A  5 3  4
>> >  [ 7] .SUNW_version VERDEF   0000578c 00578c 000038 01   A  5 2  4
>> >  [ 8] .SUNW_versym  VERSYM   000057c4 0057c4 000148 02   A  4 0  4
>>
>> AFAICT, above sections do *not* overlap, which means that there is a
>> bug in my patch (I don't see it :-(, or something else went wrong.
>>
>> >> On Fri, Sep 4, 2009 at 3:19 AM, Pierre Muller<muller@ics.u-strasbg.fr>
>> >> wrote:
>> >>
>> >> >  I checked your patch and it does solve the problem.
>> >> > Instead of a internal_error, I get a warning
>> >> > about .SUNW_version and .SUNW_versym sections
>> >> > between intertwined.
>>
>> Could you please send me the exact warning from patched GDB.

> Here you are,
> hope you can do something with it!
>
> (top-gdb) start
> Temporary breakpoint 3 at 0x80c7074: file ../../src/gdb/gdb.c, line 28.
> Starting program: /usr/local/src/gdbcvs/build/gdb/gdb
> warning: Unexpected overlap between section `.SUNW_version' from `/usr/lib/ld.so.1' [0xfefc378c, 0xfefc37ec) and section `.SUNW_versym' from `/usr/lib/ld.so.1' [0xfefc37c4, 0xfefc390c)
> [Thread debugging using libthread_db enabled]
> warning: Unexpected overlap between section `.SUNW_version' from `/usr/lib/ld.so.1' [0xfefc378c, 0xfefc37ec) and section `.SUNW_versym' from `/usr/lib/ld.so.1' [0xfefc37c4, 0xfefc390c)
> [New Thread 1 (LWP 1)]
> [Switching to Thread 1 (LWP 1)]

It seems pretty clear now that BFD (or something) is getting confused
by the presence of two separate .SUNW_version sections. In particular,
section #7 somehow acquired the size (0x60) from section #6, and that
causes the warning.

I'll go ahead and debug this today.

Thanks,
-- 
Paul Pluzhnikov

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Paul Pluzhnikov]

On Fri, Sep 4, 2009 at 8:25 AM, Paul Pluzhnikov <ppluzhnikov@google.com> wrote:

> I think there is another release blocker:

And another one :-(

We have a bug report, where doing "break file:line" inserts 13 breakpoints
with GDB CVS, but only 9 with GDB-6.8.

The problem is that the extra 4 insertions are all in the middle of
instruction(s), and cause inferior to SIGSEGV if any of these instructions
is ever executed.

This is happening in a large piece of optimized code, still working on
reduced test case. Analysis so far:

The problem appears to be in expand_line_sal(). Both gdb-6.8 and gdb-cvs
construct a list of 20 candidates, but then gdb-6.8 filters that list down
to 9, and gdb-cvs down to 13 candidates.

-- 
Paul Pluzhnikov

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Joel Brobecker]

> The problem appears to be in expand_line_sal(). Both gdb-6.8 and gdb-cvs
> construct a list of 20 candidates, but then gdb-6.8 filters that list down
> to 9, and gdb-cvs down to 13 candidates.

Humpf! Let's open a PR as soon as you have more details (I can take
care of that part if you prefer to just send the details to this list).
I propose we do NOT block the branch creation pending resolution, but
rather make this release-blocking. We can fix this issue on the branch.
Otherwise, we'll keep finding problems, and will never create that
branch.

-- 
Joel

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Paul Pluzhnikov]

On Mon, Sep 14, 2009 at 10:52 AM, Joel Brobecker <brobecker@adacore.com> wrote:

> I propose we do NOT block the branch creation pending resolution, but
> rather make this release-blocking. We can fix this issue on the branch.
> Otherwise, we'll keep finding problems, and will never create that
> branch.

That sounds good to me.

-- 
Paul Pluzhnikov

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Paul Pluzhnikov]

On Mon, Sep 14, 2009 at 10:43 AM, Paul Pluzhnikov
<ppluzhnikov@google.com> wrote:

> And another one :-(
>
> We have a bug report, where doing "break file:line" inserts 13 breakpoints
> with GDB CVS, but only 9 with GDB-6.8.
>
> The problem is that the extra 4 insertions are all in the middle of
> instruction(s), and cause inferior to SIGSEGV if any of these instructions
> is ever executed.
>
> This is happening in a large piece of optimized code, still working on
> reduced test case. Analysis so far:

This was apparetnly a false alarm: both gdb-6.8 and gdb-cvs construct an
identical list of 20 candidates, 4 of which are wrong. And then gdb-6.8
happens to filter out the wrong ones, while gdb-cvs doesn't.

The reason bad candidates are there in the first place is corrupt line
table, due to a bug in gold:
http://sourceware.org/bugzilla/show_bug.cgi?id=10400

I don't believe there is any way to detect and/or work around this in GDB.

Sorry for the noise.
-- 
Paul Pluzhnikov

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Hui Zhu]

Hi Joel,

I think it's very close to branch.

But prec still have some patches isn't in.
I am not sure they can in 7.0  or not.  Could you please help me with
it?  Thanks a lot.  :)

1.  [RFA] Make the prec support signal better
Michael have check-in the test for signal.  Without these patches.
Testsuite will get fail.

2.  Record segfault
I posted a patch for it.

3. [RFA] let record_resume fail immediately on error
Sames like 1.

4.  [RFA] reverse debugging tests
I think this patch can make reverse test more better.

5. set record query <on|off>
You are working on it too.  Wish we can find a good way to deal with
query and MI.

Thanks,
Hui

On Thu, Sep 3, 2009 at 00:44, Joel Brobecker <brobecker@adacore.com> wrote:
> Hello everyone,
>
> I think everyone is anxious to see the next release out as fast as
> we can; it is going to be a major step forward compared to the previous
> releases!
>
> First, we need to make progress on the following documented issues:
>
>  (a) Assert in frame.c:get_frame_arch
>      Basically, we added an assertion to get_frame_arch, which should
>      always be true. But to be safe, we decided to remove it from
>      the release sources if the release branch was cut before we had
>      enough time to field-test that change.  We added that assertion
>      in January, so I think we can skip that item.  I don't think we
>      ever tripped that assertion, did we?
>
>  (b) Rename the python-support files to be 8.3-compliant.
>      I thought that the change had been approved, but I see that
>      the change has not been made.  Has it been approved? If yes,
>      it is being held up because we don't know how to best rename
>      files without disturbing git?
>
>  (c) varobj support for Python pretty-printing
>      Tom gave a quick status on IRC yesterday. It sounds like
>      there isn't much left to do. Perhaps a quick update on the Wiki
>      page to state exactly what's left would be nice.  Unless fixing
>      the last thing or two might be faster ;-).
>
>  (d) PR/9711: Quadratic slowdown for "where" command.
>      Pending catastrophes, I should be able to fix that this week.
>
>  (e) PR/9786: Typing "info frame" immediately after connecting to
>      a remote target causes an assertion error on x86 GNU/Linux (32 bit).
>      That's a real regression.  I don't know that anyone ever looked
>      at this issue. I did reproduce the issue many moons ago. I don't
>      think it reproduces on x86_64.  Any taker?
>
>  (f) bug in breakpoint commands: commands not evaluated outside of
>      main command loop.
>      http://sourceware.org/ml/gdb-patches/2008-07/msg00583.html
>      There is a suggested patch, but needs looking at. Any taker?
>
> If there are any issue that you know of that are *RELEASE-CRITICAL*
> (build failure, regressions), please let us know, so we can decide
> what to do, and possibly add it to the 7.0 TODO list. Anything else,
> I suggest, should no longer be a priority for 7.0.
>
> In terms of dates, I would like us to try to release sooner rather than
> later. Can I suggest we try to shoot for Wed Sep 9th for the branch date,
> and then try to release a couple of weeks after (that would be the 23rd)?
>
> If there are any fixes that would be nice for the release but don't make
> it to the 23rd, we can always have a corrective 7.0.1 release mid
> December. Also, it sounds like a lot more new features are currently
> being developed, and people are trying to make it for 7.0. I propose to
> release 7.1 not too long after 7.0: Instead of waiting 6 months, we could
> release around end of January, early Feb (say: branch mid Jan, release
> end of Jan).
>
> Thoughts?
>
> Doug, you asked for a couple of weeks notice for 7.0. I'm being a little
> more aggressive. Is this going to be an issue for you?
>
> --
> Joel
>

Re: [gdb-7.0 release] 2009-09-02 status and proposed plan

[Joel Brobecker]

> Oh yeah, and there's the Reverese MI patches that would be nice to have
> in 7.0.  I believe everything was approved but it is delayed by
> the assignment.  I guess there's nothing to do about that
> until the legal stuff is resolved.  Hopefully it can be
> accepted after the branch.

I will not hide that adding patches of this kind, that could potentially
affect all platforms, are making me very nervous. Given that the patches
were already approved before the branch was created, I would not have had
any problem if the patches were applied right now, but I have a feeling
that the paperwork will take time to come through.  Applying just before
the release seems like a bad idea to me.

Please remind us again when the paperwork is done, and we can decide
then. If 7.0 is already out, then we don't have to make any tough
decision.

-- 
Joel