GDB 6.1 branch end jan?

GDB 6.1 branch end jan?

[Andrew Cagney]

Hello,

According to the release schedule:

	http://sources.redhat.com/gdb/schedule/

GDB 6.1 is ment to branch sometime in January.  Now that the SPARC 
rewrite has been merged (and SPARC is looking really healthy, go mark!) 
its time to come up with a more concrete set of dates.  Let's try:

	~branch 2004-01-31
	~release 2004-03-15

Andrew

Re: GDB 6.1 branch end jan?

[David Carlton]

On Wed, 07 Jan 2004 18:40:24 -0500, Andrew Cagney <cagney@gnu.org> said:

> According to the release schedule:

> 	http://sources.redhat.com/gdb/schedule/

> GDB 6.1 is ment to branch sometime in January.  Now that the SPARC
> rewrite has been merged (and SPARC is looking really healthy, go
> mark!) its time to come up with a more concrete set of dates.  Let's
> try:

> 	~branch 2004-01-31
> 	~release 2004-03-15

We're at an unfortunate state in my C++ work right now - I'm still
waiting for symtab approval for
<http://sources.redhat.com/ml/gdb-patches/2003-11/msg00242.html>, and
frankly there are more patches that would ideally go in after that.
I'm not saying that the above dates are impossible, but it would be
nice if that patch got looked at soon...

David Carlton
carlton@kealia.com

Re: GDB 6.1 branch end jan?

[Joel Brobecker]

> GDB 6.1 is ment to branch sometime in January.  Now that the SPARC 
> rewrite has been merged (and SPARC is looking really healthy, go mark!) 
> its time to come up with a more concrete set of dates.  Let's try:
> 
> 	~branch 2004-01-31
> 	~release 2004-03-15

I think it'd be nice if the following patch made it for 6.1:
http://sources.redhat.com/ml/gdb-patches/2003-11/msg00468.html

This patch adds support for DW_TAG_subrange_type DIEs that are
emitted by GCC for some Ada types (modular types, and also
enumeration subtypes). Admitedly Ada support has not been merged
in yet, but this prevents I think an error that causes at least
a complaint, and maybe even an internal error (don't remember
anymore).

(there are actually 2 patches: Andreas' and mine - mine is a bit more
complete than Andreas', but that may be unnecessary completeness.
I implemented it half mechanically, and was content when I found that
it worked :).

-- 
Joel

Re: GDB 6.1 branch end jan?

[Andrew Cagney]

PS:

I need to remember to include the following information in this initial 
post.  I always seem to receive a slew of private e-mails asking if some 
yet to be contributed/announced "port" (architecture or system) can be 
squeesed into the next release.

Per:
http://sources.redhat.com/gdb/current/onlinedocs/gdbint_15.html#SEC132

--

15.2 Branch Commit Policy

The branch commit policy is pretty slack. GDB releases 5.0, 5.1 and 5.2 
all used the below:

* The `gdb/MAINTAINERS' file still holds.
* Don't fix something on the branch unless/until it is also fixed in the 
trunk. If this isn't possible, mentioning it in the `gdb/PROBLEMS' file 
is better than committing a hack.
* When considering a patch for the branch, suggested criteria include: 
Does it fix a build? Does it fix the sequence break main; run when 
debugging a static binary?
* The further a change is from the core of GDB, the less likely the 
change will worry anyone (e.g., target specific code).
* Only post a proposal to change the core of GDB after you've sent 
individual bribes to all the people listed in the `MAINTAINERS' file ;-)

Pragmatics: Provided updates are restricted to non-core functionality 
there is little chance that a broken change will be fatal. This means 
that changes such as adding a new architectures or (within reason) 
support for a new host are considered acceptable.

--

I should also note that with 6.0, significant flexability was afforded 
to people trying to frame-ify their architecture.

Andrew

Re: GDB 6.1 branch end jan?

[Elena Zannoni]

David Carlton writes:
 > On Wed, 07 Jan 2004 18:40:24 -0500, Andrew Cagney <cagney@gnu.org> said:
 > 
 > > According to the release schedule:
 > 
 > > 	http://sources.redhat.com/gdb/schedule/
 > 
 > > GDB 6.1 is ment to branch sometime in January.  Now that the SPARC
 > > rewrite has been merged (and SPARC is looking really healthy, go
 > > mark!) its time to come up with a more concrete set of dates.  Let's
 > > try:
 > 
 > > 	~branch 2004-01-31
 > > 	~release 2004-03-15
 > 
 > We're at an unfortunate state in my C++ work right now - I'm still
 > waiting for symtab approval for
 > <http://sources.redhat.com/ml/gdb-patches/2003-11/msg00242.html>, and
 > frankly there are more patches that would ideally go in after that.
 > I'm not saying that the above dates are impossible, but it would be
 > nice if that patch got looked at soon...
 > 

I did start reviewing that patch at the time, but got distracted for a
few weeks and totally forgot about it.  I am looking at it right now.

How many more patches after that are left?


elena

Re: GDB 6.1 branch end jan?

[David Carlton]

On Thu, 8 Jan 2004 15:02:20 -0500, Elena Zannoni <ezannoni@redhat.com> said:

> I did start reviewing that patch at the time, but got distracted for
> a few weeks and totally forgot about it.  I am looking at it right
> now.

Thanks!

> How many more patches after that are left?

Good question.  If I'm remembering correctly, the three main loose
ends involved function overloading, lookup_transparent_type, and
linespec.  I think Daniel can approve function overloading by himself,
because we moved the relevant code out of symtab.c and into
cp-support.c.  The lookup_transparent_type change is perhaps the most
important, but I'll try to generate the patch in such a way that the
C++-specific stuff goes in cp-support.c, so you won't have much work
to do there.  The linespec.c patch will require your approval,
however, since you're the only linespec maintainer.

I think I should be able to generate the patches in question
reasonably quickly; work is keeping me busy, but we don't have any
immediate deadlines coming up or anything, so I should be able to
steal a few hours to work on GDB.

David Carlton
carlton@kealia.com

Re: GDB 6.1 branch end jan?

[Elena Zannoni]

Joel Brobecker writes:
 > > GDB 6.1 is ment to branch sometime in January.  Now that the SPARC 
 > > rewrite has been merged (and SPARC is looking really healthy, go mark!) 
 > > its time to come up with a more concrete set of dates.  Let's try:
 > > 
 > > 	~branch 2004-01-31
 > > 	~release 2004-03-15
 > 
 > I think it'd be nice if the following patch made it for 6.1:
 > http://sources.redhat.com/ml/gdb-patches/2003-11/msg00468.html
 > 
 > This patch adds support for DW_TAG_subrange_type DIEs that are
 > emitted by GCC for some Ada types (modular types, and also
 > enumeration subtypes). Admitedly Ada support has not been merged
 > in yet, but this prevents I think an error that causes at least
 > a complaint, and maybe even an internal error (don't remember
 > anymore).
 > 
 > (there are actually 2 patches: Andreas' and mine - mine is a bit more
 > complete than Andreas', but that may be unnecessary completeness.
 > I implemented it half mechanically, and was content when I found that
 > it worked :).
 > 

another one for me. will do next.

elena

 > -- 
 > Joel

Re: GDB 6.1 branch end jan?

[Andrew Cagney]

> Hello,
> 
> According to the release schedule:
> 
>     http://sources.redhat.com/gdb/schedule/
> 
> GDB 6.1 is ment to branch sometime in January.  Now that the SPARC rewrite has been merged (and SPARC is looking really healthy, go mark!) its time to come up with a more concrete set of dates.  Let's try:
> 
>     ~branch 2004-01-31
>     ~release 2004-03-15

Looking at my rate of change with TUI, and knowing I'm off line the next 
two weekends, and looking at the IBM stuff, and steady progress on other 
fronts, I think I'll slip this two weeks vis:

	branch 2004-02-14
	release 2004-03-30

Andrew

Re: GDB 6.1 branch end jan?

[David Carlton]

On Fri, 23 Jan 2004 18:30:59 -0500, Andrew Cagney <cagney@gnu.org> said:

> Looking at my rate of change with TUI, and knowing I'm off line the
> next two weekends, and looking at the IBM stuff, and steady progress
> on other fronts, I think I'll slip this two weeks vis:

> 	branch 2004-02-14
> 	release 2004-03-30

That should be fine from my point of view.  Elena and Daniel have been
really responsive (thanks!), and I've been able to steal enough time
from my primary duties at work that I should be able to generate the
last few important patches in time for the 6.1 branch (never mind the
release).

David Carlton
carlton@kealia.com

Re: GDB 6.1 branch end jan?

[Michael Elizabeth Chastain]

> branch 2004-02-14
> release 2004-03-30

Looks pretty good to me right now.  We got this big lump of bugs
from David's merge, but they are getting fixed pretty quick.

I'll put up another "6.0 versus HEAD" comparison in 24-48 hours.

Michael C

Re: GDB 6.1 branch end jan?

[Michael Elizabeth Chastain]

Andrew C writes:

	~branch 2004-01-31
	~release 2004-03-15

I'm comfortable with 6 weeks for branch-to-release.

I think 2004-01-31 is okay, depending on whether people spend time
fixing high-priority bugs or not.  If they don't fix the bugs before the
branch then we will have to fix them on both branch and HEAD and that's
just more work.  If we have known bugs, and you decide we have to fix
them, then I'd rather branch later and release earlier.

bugs with priority=high (4):

  http://sources.redhat.com/gdb/bugs/1417
  crash when printing variables

  http://sources.redhat.com/gdb/bugs/1405
  regression: print pEe->vf(), virtual baseclass both, g++ 2.95.3 -gdwarf-2

  http://sources.redhat.com/gdb/bugs/1398
  Path handling bug which makes GDB unable to stop at breakpoints

  http://sources.redhat.com/gdb/bugs/378
  ``GNU/Linux" ``Linux kernel"

bugs with severity=critical marked "regression" (1):

  http://sources.redhat.com/gdb/bugs/1501
  [regression] src-release broken, uses obsolete sun4 configuration

There are 47 total severity=critical bugs.

This bug deserves high priority:

  http://sources.redhat.com/gdb/bugs/1470
  ELF_LINK_POINTER_EQUALITY_NEEDED breaks shlib-call.exp

    binutils HEAD has a new PLT optimization which gdb does not handle.
    I say it's a problem in binutils but Jakub J says it's a problem in gdb.

Coverage with gcc HEAD -gstabs+ has not been available since the ABI
upgrade.  (That's why I haven't published a report since before the
ABI change.  I have to fix some more gdb.cp/*.exp files, and I've been
waiting a week for any more fallout from my last rewrite).  I'd like
to have some more visibility from this before branch.

If I've been doing the sunday project perfectly, then every test result
regression from gdb 6.0 has already turned into a priority=high bug with
"regression" in the name.  But I may have missed something.  So there
might be about 1 more bug in there when I examine the "compare by gdb"
tables.  I estimate 0.1 to 0.3 bugs.  :)

hppa*-hp-hpux* support is better than 6.0 (it would be hard to be worse
than "does not build"), but it's probably worse than the last good gdb
version, whatever that was.  It passes the "break main" test, at least
when gdb itself is built with gcc.

Michael C