quick status on gdb-7.2.1 & gdb-7.3? (Mar 07)

quick status on gdb-7.2.1 & gdb-7.3? (Mar 07)

[Joel Brobecker]

Hello everyone,

It's been a while since we last really talked about the release,
can we have a quick status on the various items we're waiting for?
Right now, we're about 3 weeks late.

  - The big blockers for the release are (regressions) [Keith, Jan]:
       c++/11734
       c++/12273
    It sounded like Keith and Jan are making progress, and getting
    closer to a solution that doesn't introduces other regressions.
    How far do we think we are?

For GDB 7.3, we have, in addition to the above:

  - ifunc branch (might be close to being merge-ready) [Jan]

  - exposing SystemTap static probe points [Sergio, Tom]

  - tracepoint printf support [Hui] (awaiting review)

  - <unavailable> values support (part 3) [Pedro]
     http://sourceware.org/ml/gdb-patches/2011-02/msg00581.html
     http://sourceware.org/ml/gdb-patches/2011-02/msg00611.html
    It's been waiting for comments a while, now, so should be
    ready to commit soon?

My understanding is that we don't really need to wait for the
ifunc and SystemTap stuff if it's going to delay the release.
Only a nice to have.

I don't think that Hui's tracepoint printf patch is a critical
patch either, but it's been waiting for review for a while, now,
and it'd be nice to at least review it before we branch. Anyone,
competent in this area, please?

So, all in all, I think we're just blocked by the C++ regressions.
As soon as they are resolved, we can start thinking about branching.

-- 
Joel

Re: quick status on gdb-7.2.1 & gdb-7.3? (Mar 07)

[Joel Brobecker]

> For GDB 7.3, we have, in addition to the above:

I forgot something important: Remove configure & make out of common/.
We'll probably want a small observation period after we make that
change, before we branch...

-- 
Joel

Re: quick status on gdb-7.2.1 & gdb-7.3? (Mar 07)

[Tom Tromey]

Joel> My understanding is that we don't really need to wait for the
Joel> ifunc and SystemTap stuff if it's going to delay the release.
Joel> Only a nice to have.

I think ifunc is more important.  Without ifunc, a very common idiom
will not work on recent glibc-based systems:

    cond 5 !strcmp(arg, "whatever")

Tom

Re: quick status on gdb-7.2.1 & gdb-7.3? (Mar 07)

[Joel Brobecker]

> I think ifunc is more important.  Without ifunc, a very common idiom
> will not work on recent glibc-based systems:
> 
>     cond 5 !strcmp(arg, "whatever")

OK - I have moved this task to the non-optional part of the TODO
list for GDB 7.3.  Do we have a rough estimate on how soon we might
be able to merge this code?

-- 
Joel

Re: quick status on gdb-7.2.1 & gdb-7.3? (Mar 07)

[Jan Kratochvil]

On Tue, 08 Mar 2011 06:13:15 +0100, Joel Brobecker wrote:
> > I think ifunc is more important.  Without ifunc, a very common idiom
> > will not work on recent glibc-based systems:
> > 
> >     cond 5 !strcmp(arg, "whatever")
> 
> OK - I have moved this task to the non-optional part of the TODO
> list for GDB 7.3.  Do we have a rough estimate on how soon we might
> be able to merge this code?

It works without bugs but various cases are suboptimal there but I do not
remember which ones.  Working on it today as I was just procrastinating the
linespec review anyway.


Jan

Re: quick status on gdb-7.2.1 & gdb-7.3? (Mar 07)

[Jan Kratochvil]

On Mon, 07 Mar 2011 13:27:32 +0100, Joel Brobecker wrote:
> For GDB 7.3, we have, in addition to the above:

FYI worth considering is a gcc-4.6 bug workaround for GDB:
	http://sourceware.org/bugzilla/show_bug.cgi?id=12435

But it should be fixed for gcc-4.6.0 GA so maybe GDB does not have to care.


Thanks for doing the work,
Jan

Re: quick status on gdb-7.2.1 & gdb-7.3? (Mar 07)

[Joel Brobecker]

> FYI worth considering is a gcc-4.6 bug workaround for GDB:
> 	http://sourceware.org/bugzilla/show_bug.cgi?id=12435
> 
> But it should be fixed for gcc-4.6.0 GA so maybe GDB does not have to care.

Normally, I would say that we should be resilient to debug info
bugs. In this particular case, the decision is a little harder
to take, because it appears that the bug does not appear in a
GCC release (and hopefully won't); and also, the fix is in a
sensitive area... That being said, I don't have a particular
objection to the fix if it doesn't complexify the code too much,
and some comments are added.

-- 
Joel