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

[Jack Howarth <howarth@bromo.med.uc.edu>]

  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