gdb 7.0: 5 weeks to branch-time...

gdb 7.0: 5 weeks to branch-time...

[Joel Brobecker]

Hello everyone,

We're getting closer to our desired branch time, so I thought
a quick update on our situation would be nice. I'm looking at
our TODO list for this release
(http://www.sourceware.org/gdb/wiki/GDB_7.0_Release):

  * Assert in frame.c:get_frame_arch
    I don't think anyone actually triggered that assert so far, so
    we might not have to remove it from the branch. We can postpone
    that decision for after we've created the branch.

  * Python: Pretty printing
    Done?

  * Inlining support
    Mark to provide some feedback about the proposed patch.

  * PR/9711: Quadratic slowdown for "where" command. 
    I don't think anyone worked on that one so far. Any volunteer?

Optional items:

  * Python: Support for new parameters and/or convenience functions
    (?) I forgot what this means :-(

  * Process record and replay:
    Sounds like this is still underway

  * Multiprocess support:
    Sounds like work is also underway. Status update on how far we are?

Thanks, everyone. I can't wait to see 7.0 out :).

-- 
Joel

Re: gdb 7.0: 5 weeks to branch-time...

[Tom Tromey]

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

Joel>   * Python: Pretty printing
Joel>     Done?

The feature itself is largely complete.  We have two known issues:

1. Pretty-printing base classes in C++.  Phil is putting the finishing
touches on the fix for this now.

2. Changing some internals to allow printing of strings with embedded
NUL characters.

I'm in the process now of prepping the patches for submission.
Phil's patch might make it into these, or might be a follow-up patch.
The second item should be fixed in the near future.

Joel>   * Python: Support for new parameters and/or convenience functions
Joel>     (?) I forgot what this means :-(

Convenience functions are in.  Parameters aren't, but I suppose they
could be submitted.

Convenience functions let users write new functions in Python.  They
are represented as convenience variables of a special internal type.

New parameters just means being able to add new "set/show" commands
from Python.


Another nice-to-have is Sérgio's "catch syscall" patch.  It seems to
be very close to completion.

Tom

Re: gdb 7.0: 5 weeks to branch-time...

[Thiago Jung Bauermann]

El mié, 01-04-2009 a las 16:13 -0600, Tom Tromey escribió:
> >>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:
> Joel>   * Python: Support for new parameters and/or convenience functions
> Joel>     (?) I forgot what this means :-(
> 
> Convenience functions are in.  Parameters aren't, but I suppose they
> could be submitted.

Submitting a patch for parameters in python is in my TODO list for the
next couple of weeks.
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

Re: gdb 7.0: 5 weeks to branch-time...

[Joel Brobecker]

Hi Tom,
> The feature itself is largely complete.  We have two known issues:
> 
> 1. Pretty-printing base classes in C++.  Phil is putting the finishing
> touches on the fix for this now.
> 
> 2. Changing some internals to allow printing of strings with embedded
> NUL characters.

I've updated the wiki to mention these two issues. Would either of you
mind updating the wiki again when it's taken care of?

-- 
Joel

Re: gdb 7.0: 5 weeks to branch-time...

[Tom Tromey]

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

>> 1. Pretty-printing base classes in C++.  Phil is putting the finishing
>> touches on the fix for this now.

Joel> I've updated the wiki to mention these two issues. Would either of you
Joel> mind updating the wiki again when it's taken care of?

No problem.  Phil checked in the fix for #1 today.  So, it will show
up in the initial submission of this feature.

He's started work on #2 now as well :-)

Tom

Re: gdb 7.0: 5 weeks to branch-time...

[Eli Zaretskii]

> Date: Wed, 1 Apr 2009 14:58:27 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> 
> Hello everyone,
> 
> We're getting closer to our desired branch time, so I thought
> a quick update on our situation would be nice. I'm looking at
> our TODO list for this release
> (http://www.sourceware.org/gdb/wiki/GDB_7.0_Release):
> 
>   * Assert in frame.c:get_frame_arch
>     I don't think anyone actually triggered that assert so far, so
>     we might not have to remove it from the branch. We can postpone
>     that decision for after we've created the branch.
> 
>   * Python: Pretty printing
>     Done?
> 
>   * Inlining support
>     Mark to provide some feedback about the proposed patch.
> 
>   * PR/9711: Quadratic slowdown for "where" command. 
>     I don't think anyone worked on that one so far. Any volunteer?
> 
> Optional items:
> 
>   * Python: Support for new parameters and/or convenience functions
>     (?) I forgot what this means :-(
> 
>   * Process record and replay:
>     Sounds like this is still underway
> 
>   * Multiprocess support:
>     Sounds like work is also underway. Status update on how far we are?
> 
> Thanks, everyone. I can't wait to see 7.0 out :).

I still have the issues with file names reported here:

  http://sourceware.org/ml/gdb-patches/2009-03/msg00618.html

I take it that the silence means everyone agrees with the renaming?
If so, I will give it a go in a day or two.

Re: gdb 7.0: 5 weeks to branch-time...

[Daniel Jacobowitz]

On Thu, Apr 02, 2009 at 06:24:14AM +0300, Eli Zaretskii wrote:
> I still have the issues with file names reported here:
> 
>   http://sourceware.org/ml/gdb-patches/2009-03/msg00618.html
> 
> I take it that the silence means everyone agrees with the renaming?
> If so, I will give it a go in a day or two.

We import these files from gnulib.  Any time we import them, they'll
get the same names.  Maybe you could raise this problem with the
gnulib developers?

-- 
Daniel Jacobowitz
CodeSourcery

Re: gdb 7.0: 5 weeks to branch-time...

[Eli Zaretskii]

> Date: Thu, 2 Apr 2009 11:11:37 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Joel Brobecker <brobecker@adacore.com>, gdb@sourceware.org
> 
> On Thu, Apr 02, 2009 at 06:24:14AM +0300, Eli Zaretskii wrote:
> > I still have the issues with file names reported here:
> > 
> >   http://sourceware.org/ml/gdb-patches/2009-03/msg00618.html
> > 
> > I take it that the silence means everyone agrees with the renaming?
> > If so, I will give it a go in a day or two.
> 
> We import these files from gnulib.  Any time we import them, they'll
> get the same names.

Can't the import script rename them?

> Maybe you could raise this problem with the gnulib developers?

I don't think I stand a chance, unless GDB as a project will ask for
that.

Re: gdb 7.0: 5 weeks to branch-time...

[Daniel Jacobowitz]

On Thu, Apr 02, 2009 at 10:38:22PM +0300, Eli Zaretskii wrote:
> > Date: Thu, 2 Apr 2009 11:11:37 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Joel Brobecker <brobecker@adacore.com>, gdb@sourceware.org
> > 
> > On Thu, Apr 02, 2009 at 06:24:14AM +0300, Eli Zaretskii wrote:
> > > I still have the issues with file names reported here:
> > > 
> > >   http://sourceware.org/ml/gdb-patches/2009-03/msg00618.html
> > > 
> > > I take it that the silence means everyone agrees with the renaming?
> > > If so, I will give it a go in a day or two.
> > 
> > We import these files from gnulib.  Any time we import them, they'll
> > get the same names.
> 
> Can't the import script rename them?

The import script comes from gnulib...

> > Maybe you could raise this problem with the gnulib developers?
> 
> I don't think I stand a chance, unless GDB as a project will ask for
> that.

I can't see why not.  You're an interested developer in your own right.

-- 
Daniel Jacobowitz
CodeSourcery

Re: gdb 7.0: 5 weeks to branch-time...

[Eli Zaretskii]

> Date: Thu, 2 Apr 2009 23:37:49 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: brobecker@adacore.com, gdb@sourceware.org
> 
> > > Maybe you could raise this problem with the gnulib developers?
> > 
> > I don't think I stand a chance, unless GDB as a project will ask for
> > that.
> 
> I can't see why not.

Experience and gray hair.

Re: gdb 7.0: 5 weeks to branch-time...

[Thiago Jung Bauermann]

El mié, 01-04-2009 a las 14:58 -0700, Joel Brobecker escribió:
> We're getting closer to our desired branch time, so I thought
> a quick update on our situation would be nice. I'm looking at
> our TODO list for this release
> (http://www.sourceware.org/gdb/wiki/GDB_7.0_Release):

There are two bugzillas that I think should be addressed for 7.0.
Actually, only one of those would need to be fixed for 7.0:

PR/9174 - gdb can't handle PIE
PR/9723 - gdb breakpoints silently fail on PIE binaries

The latter is actually about adding a warning stating that PIE binaries
are not supported, when GDB detects that it's handling one of those,
while we don't fix PR/9174.

Since it's probably somewhat difficult to add full PIE support, I think
we should aim to fix PR/9174 in 7.1, and fix PR/9723 for 7.0. Hence, I'd
like to add PR/9723 to the "issues which should be addressed before the
7.0 release" list in the wiki, and PR/9174 to the "optional action
items" list. WDYT?

> Thanks, everyone. I can't wait to see 7.0 out :).

+1!
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

Re: gdb 7.0: 5 weeks to branch-time...

[Joel Brobecker]

> Since it's probably somewhat difficult to add full PIE support, I think
> we should aim to fix PR/9174 in 7.1, and fix PR/9723 for 7.0. Hence, I'd
> like to add PR/9723 to the "issues which should be addressed before the
> 7.0 release" list in the wiki, and PR/9174 to the "optional action
> items" list. WDYT?

Sounds good to me, Thiago. Go ahead if you haven't already done so.

-- 
Joel

Re: gdb 7.0: 5 weeks to branch-time...

[Pedro Alves]

On Wednesday 01 April 2009 22:58:27, Joel Brobecker wrote:
>   * Multiprocess support:
>     Sounds like work is also underway. Status update on how far we are?

 Most of the gdbserver bits required for multi-process are now in
mainline.  I've left remote protocol support for follow-fork and
follow-exec support in the branch, as I'm not completelly happy
with the implementation there.

Then there's a lot to do:

  1) Basic native linux multiprocess support.
  2) Add multi-executable support
  3) Make breakpoints aware of execs/address-spaces/inferiors
  4) CLI syntax for the 2-4 above
  5) Shared-libraries per-inferior

Plus a bunch of things mentioned in the MultiProcess wiki page
that need to be fixed.

#1 I'm cleaning up right now for submission.

Maybe with this in place it will be easier to recruit
some help.  :-)

#2 and #3 and #4 are in the multi-process branch, but, they
need work to make it suitable for targets that share code
across inferiors.  There are a couple of hacks in there to
fix too.  #3 needs addressing of the issues raised in
the wiki page.

#5 needs doing.

We're a few weeks away from having this done, hopefuly,
before branch-time.

-- 
Pedro Alves