Delay the branch for E500 native support

Delay the branch for E500 native support

[Jim Blandy]

Would it be possible to delay the GDB 6.2 branch for another week,
until Fri, July 9th?

It would be really nice for 6.2 to contain full, unqualified native
PowerPC E500 Linux support.  We're really close.  The bulk of it is
committed and working.  The two missing pieces are that you can't
access the E500's vector registers in multi-threaded programs, and you
can't refer to variables located in vector registers, because of GCC's
use of DW_OP_piece.  I've posted patches to address the first problem,
which are being discussed for revision, and I'm working on patches for
the second issue, revised as discussed in the thread at:

    http://sources.redhat.com/ml/gdb-patches/2003-05/msg00425.html

I'm happy to put in time over the U.S. holiday weekend, and do what it
takes next week to get it all posted for further review by midweek.
If maintainers can give me detailed instructions on how they want the
patches revised, I'll be happy to comply.

I'd just really like to be able to say, in the GDB 6.2 NEWS: "Added
support for native PowerPC E500 Linux", without qualifications.

Re: Delay the branch for E500 native support

[Daniel Jacobowitz]

On Fri, Jul 02, 2004 at 05:26:35PM -0500, Jim Blandy wrote:
> 
> Would it be possible to delay the GDB 6.2 branch for another week,
> until Fri, July 9th?
> 
> It would be really nice for 6.2 to contain full, unqualified native
> PowerPC E500 Linux support.  We're really close.  The bulk of it is
> committed and working.  The two missing pieces are that you can't
> access the E500's vector registers in multi-threaded programs, and you
> can't refer to variables located in vector registers, because of GCC's
> use of DW_OP_piece.  I've posted patches to address the first problem,
> which are being discussed for revision, and I'm working on patches for
> the second issue, revised as discussed in the thread at:
> 
>     http://sources.redhat.com/ml/gdb-patches/2003-05/msg00425.html

DW_OP_piece will presumably be a substantial change.  While I'd love to
see it in GDB 6.2:
  (A) A week before the branch is not a good time for huge new
features.
  (B) it can be merged after the branch is cut, once it is known to
work on HEAD and has been tested - in fact this is probably preferable
to committing before the branch.

The vector register stuff I have no comments about, since it's not
going to affect other targets in the same way.  That's an even better
candidate for committing to the branch after branching.

> I'm happy to put in time over the U.S. holiday weekend, and do what it
> takes next week to get it all posted for further review by midweek.
> If maintainers can give me detailed instructions on how they want the
> patches revised, I'll be happy to comply.
> 
> I'd just really like to be able to say, in the GDB 6.2 NEWS: "Added
> support for native PowerPC E500 Linux", without qualifications.

I would really have liked for GDB 6.1 to contain inter-compilation-unit
reference support too.  If the timing doesn't work out, it doesn't work
out - if the schedule holds there may even be another release this
year.

-- 
Daniel Jacobowitz

Re: Delay the branch for E500 native support

[Eli Zaretskii]

> Date: Fri, 2 Jul 2004 18:40:47 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> I would really have liked for GDB 6.1 to contain inter-compilation-unit
> reference support too.  If the timing doesn't work out, it doesn't work
> out - if the schedule holds there may even be another release this
> year.

The intercu example is not a good analogy, IMHO: it was a new feature
that was totally absent from the codebase.

Jim's situation is somewhat different: there's a half-baked port
already in the CVS.  To me, it doesn't make sense to release a new
version with incomplete support for some platform, where work is under
way to make it complete in a week or so.

But then I never liked the ``release every N months no matter what''
policy, either.  What's so sacred about having the release happen on
a certain date in July, anyway?

Re: Delay the branch for E500 native support

[Daniel Jacobowitz]

On Sat, Jul 03, 2004 at 12:22:37PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 2 Jul 2004 18:40:47 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > I would really have liked for GDB 6.1 to contain inter-compilation-unit
> > reference support too.  If the timing doesn't work out, it doesn't work
> > out - if the schedule holds there may even be another release this
> > year.
> 
> The intercu example is not a good analogy, IMHO: it was a new feature
> that was totally absent from the codebase.
> 
> Jim's situation is somewhat different: there's a half-baked port
> already in the CVS.  To me, it doesn't make sense to release a new
> version with incomplete support for some platform, where work is under
> way to make it complete in a week or so.

First of all, the e500 port has been in CVS as a target port, and
continuously evolving, for a long time - since before the release of
GDB 6.1.  Secondly, it will require a DWARF feature which is
genericly used by GCC on all platforms, that we currently throw up our
hands at just like we do for inter-cu referenes.

But I was not trying to compare the two; I simply picked an example out
of my mailbox.  Perhaps it was a bad choice of example.

We've chosen to release GDB according to a schedule, or at least to
make an effort in that direction.  I think it's a reasonable choice,
but if you don't agree then we can discuss that.  But pushing dates
back for one feature at a time is not a good way to finish anything;
either we're trying for a date or we aren't.

My two cents.

-- 
Daniel Jacobowitz

Re: Delay the branch for E500 native support

[Eli Zaretskii]

> Date: Sun, 4 Jul 2004 02:13:51 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> We've chosen to release GDB according to a schedule, or at least to
> make an effort in that direction.  I think it's a reasonable choice,
> but if you don't agree then we can discuss that.  But pushing dates
> back for one feature at a time is not a good way to finish anything;
> either we're trying for a date or we aren't.

Perhaps it wasn't clear, but all I was trying to say was that I think
Jim's request is reasonable.

Re: Delay the branch for E500 native support

[Michael Elizabeth Chastain]

The disadvantage of feature-based scheduling is that right after
each feature comes one more feature.

I think it's too early to branch because there are still too many
regressions from 6.1.1: two PR's on native i686-pc-linux-gnu, and
probably two or three more on native hppa2.0w-hp-hpux11.00 if I ever get
to the bottom of analyzing them.  (Right now I'm working on yet another
debug info regression in gcc HEAD).

But that's a different reason.

Michael C

Re: Delay the branch for E500 native support

[Eli Zaretskii]

> Date: Sat,  3 Jul 2004 07:45:43 -0400 (EDT)
> From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
> 
> The disadvantage of feature-based scheduling is that right after
> each feature comes one more feature.

I didn't suggest feature-based schedule, I just said that we shouldn't
be treating time-based schedule as too sacred.

Also, we are not talking about adding a new feature, we are talking
about finishing a feature that's already in the codebase.

Re: Delay the branch for E500 native support

[Jim Blandy]

For what it's worth, I actually like feature-based scheduling, too.
It's inconsistent of me to suggest a delay.

I think my real motivation was just frustration: I've put, what, 45
patches in on this thing so far, and I really wanted to just get it
done.

I don't see any compelling reason to delay the branch.  I'll get
everything onto the trunk, and we can see what people think.