Our next GDB release (GDB version 6.8)

Our next GDB release (GDB version 6.8)

[Joel Brobecker]

Hello GDB enthusiasts!

The schedule on the GDB website shows that we were planning on
making a new GDB release (GDB version 6.8) soon: Branch creation
on Feb 5th, and a then an official release a month later.
Looks like it's going to be tight to make these dates, but
I don't think it's a problem.

I would like us to start drawing a list of things that we'd like
to include in that release. For one, I'd like to list the changes
I submitted regarding Ada support, at least the ones that provide
the most value. Maybe I'll also find some time to work on something
we briefly discussed a few years back regarding the README file, and
maybe think about the NEWS file too.  That's not critical though,
just making the release slightly more labor intensive.

I propose we use a wiki page again. In fact, I was surprised to
see that someone already created one. Should I thank Nick for that?

Opinions? Items that should be put on the list of things to finish
for the release? Please send them here and I'll add them to the
wiki. If a thread was already started, please post a link to it
as well.

Thanks,
-- 
Joel

Re: Our next GDB release (GDB version 6.8)

[Eli Zaretskii]

> Date: Fri, 25 Jan 2008 16:53:19 -0800
> From: Joel Brobecker <brobecker@adacore.com>
> 
> I would like us to start drawing a list of things that we'd like
> to include in that release. For one, I'd like to list the changes
> I submitted regarding Ada support, at least the ones that provide
> the most value. Maybe I'll also find some time to work on something
> we briefly discussed a few years back regarding the README file, and
> maybe think about the NEWS file too.  That's not critical though,
> just making the release slightly more labor intensive.
> 
> I propose we use a wiki page again.

Why wiki? why not have a file of things to do in our CVS, like Emacs
does in its admin/FOR-RELEASE file?

If you wanted to publish this to a wider audience than those who
habitually resync with CVS, you could reflect that file in the GDB Web
page somewhere.

Re: Our next GDB release (GDB version 6.8)

[Joel Brobecker]

> Why wiki? why not have a file of things to do in our CVS, like Emacs
> does in its admin/FOR-RELEASE file?

That's the way we did it before so that people less involved in
the project or the release process had an idea of what blocking issues
were still remaining before we could make the release.

> If you wanted to publish this to a wider audience than those who
> habitually resync with CVS, you could reflect that file in the GDB Web
> page somewhere.

The GDB wiki is accessible from the GDB webpage. Click on "wiki"
on the top banner, and then you'll see a link to "GDB_6.8_Release".
That's how I found that we already had a page created for it.

-- 
Joel

Re: Our next GDB release (GDB version 6.8)

[Eli Zaretskii]

> Date: Sat, 26 Jan 2008 05:59:35 -0800
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb@sourceware.org
> 
> > Why wiki? why not have a file of things to do in our CVS, like Emacs
> > does in its admin/FOR-RELEASE file?
> 
> That's the way we did it before so that people less involved in
> the project or the release process had an idea of what blocking issues
> were still remaining before we could make the release.

Well, in that case, how about having a copy of that in CVS?  I dislike
when I need to go out to the Web to see something that is so closely
related with the source tree.

Re: Our next GDB release (GDB version 6.8)

[Joel Brobecker]

> Well, in that case, how about having a copy of that in CVS?  I dislike
> when I need to go out to the Web to see something that is so closely
> related with the source tree.

The problem with that is that you then add the overhead of CVS,
ChangeLogs, emails, etc. Is checking on the web really that bad?
I used to maintain that list privately on a piece of paper. A CVS
file is a lot more effort.

-- 
Joel

Re: Our next GDB release (GDB version 6.8)

[Eli Zaretskii]

> Date: Sat, 26 Jan 2008 08:06:43 -0800
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb@sourceware.org
> 
> Is checking on the web really that bad?

It's a nuisance.

> I used to maintain that list privately on a piece of paper. A CVS
> file is a lot more effort.

How much effort would be to maintain a single text file?

Re: Our next GDB release (GDB version 6.8)

[Christopher Faylor]

On Sat, Jan 26, 2008 at 06:36:22PM +0200, Eli Zaretskii wrote:
>> Date: Sat, 26 Jan 2008 08:06:43 -0800
>> From: Joel Brobecker <brobecker@adacore.com>
>> Cc: gdb@sourceware.org
>> 
>> Is checking on the web really that bad?
>
>It's a nuisance.
>
>> I used to maintain that list privately on a piece of paper. A CVS
>> file is a lot more effort.
>
>How much effort would be to maintain a single text file?

Maybe this is obvious but the GDB web pages are CVS-backed so you could
just check a text (or html) file into /cvs/gdb/htdocs and it would show
up on the web page automatically.

cgf
(another dinosaur who dislikes wiki)

Re: Our next GDB release (GDB version 6.8)

[Eli Zaretskii]

> Date: Sat, 26 Jan 2008 11:59:57 -0500
> From: Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org>
> 
> Maybe this is obvious but the GDB web pages are CVS-backed so you could
> just check a text (or html) file into /cvs/gdb/htdocs and it would show
> up on the web page automatically.

Sure, but that's a different repository.

I actually happen to think that all files related to a project's
maintenance should be part of its repository.  Sounds kinda
reasonable, doesn't it?

Re: Our next GDB release (GDB version 6.8)

[Joel Brobecker]

> Maybe this is obvious but the GDB web pages are CVS-backed so you could
> just check a text (or html) file into /cvs/gdb/htdocs and it would show
> up on the web page automatically.

Not the wiki part. Chris, I am like you, I don't like the wiki and
I balked when some people at AdaCore talked about introducing the wiki
to store of our internal knowledge.  But in this case, this is
an informal list that I used to maintain in handwriting on a piece of paper.
The wiki here allows me to share that information easily. It's like a
buletin board.

-- 
Joel

PS: Can I join the dinausor club? My credentials are: I barely use
    the mouse. The only reason why I use X is that I can pack more
    characters on my screen. I use vim, sed, awk, and I'm still
    using fvwm. But I'll admit one sin, though. I dumped RCS and
    I'm losing faith in CVS. :-)

Re: Our next GDB release (GDB version 6.8)

[Joel Brobecker]

Eli,

I am attached to the web medium in this case, which is very unusual
for me, because I find it (again, in this case), very convenient
that people who don't have a CVS checkout can see how much progress
we're making towards the release. I also find it easy to edit, and
I like the fact that it's nicely formatted and provides hyperlinks.

> > Is checking on the web really that bad?
> 
> It's a nuisance.

Can you add a link to that page in your bookmark? Instead of opening
up an editor to see that file, you would click on the link instead.

I don't want to explain myself how maintaining a mirror file of that
list in CVS is going to be extra work. I'm prepared to do whatever
the group thinks is going to benefit the GDB project. If the others
agree with you, then fine, let's do it.

-- 
Joel

Re: Our next GDB release (GDB version 6.8)

[Nicholas Mc Guire]

> > Date: Fri, 25 Jan 2008 16:53:19 -0800
> > From: Joel Brobecker <brobecker@adacore.com>
> >
> > I would like us to start drawing a list of things that we'd like
> > to include in that release. For one, I'd like to list the changes
A bit off topic maybe - but I would like to know if it would be posible
to include the tracepoints implementation we did for gdb 6.3,6.4,6.5,6.6
as maintaining it off-tree is a bit of a wast of energy and time
A first port for CELL PPE/SPU is also available.

The gdb tracepoint patches + manual can be found at:
ftp://dslab.lzue.du.cn:/pub/tracepoints/

pleas let me know if this is posible and what we need to do to make this
happen.

thx!
hofrat

Re: Our next GDB release (GDB version 6.8)

[Daniel Jacobowitz]

On Sat, Jan 26, 2008 at 11:37:44PM -0900, Nicholas Mc Guire wrote:
> 
> 
> > > Date: Fri, 25 Jan 2008 16:53:19 -0800
> > > From: Joel Brobecker <brobecker@adacore.com>
> > >
> > > I would like us to start drawing a list of things that we'd like
> > > to include in that release. For one, I'd like to list the changes
> A bit off topic maybe - but I would like to know if it would be posible
> to include the tracepoints implementation we did for gdb 6.3,6.4,6.5,6.6
> as maintaining it off-tree is a bit of a wast of energy and time
> A first port for CELL PPE/SPU is also available.
> 
> The gdb tracepoint patches + manual can be found at:
> ftp://dslab.lzue.du.cn:/pub/tracepoints/

That URL does not exist...

> pleas let me know if this is posible and what we need to do to make this
> happen.

As with any contribution, the first step is copyright assignment - the
author needs to contact the FSF.  If you're interested in doing this,
let me know and I can send you the form.  Then the second step is to
post the changes to gdb-patches.

I don't think anything large will make 6.8 at this date but there's
always another release.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Our next GDB release (GDB version 6.8)

[Daniel Jacobowitz]

On Mon, Jan 28, 2008 at 11:20:06PM -0900, Nicholas Mc Guire wrote:
> the problem is that the project was funded by Siemens AG and they agreed
> to release it under GPL but are not able to assign copyright to another
> copany/organisation.

Then, no.  Sorry :-(  I wish you luck changing their mind.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Our next GDB release (GDB version 6.8)

[Eli Zaretskii]

> Date: Mon, 28 Jan 2008 23:20:06 -0900 (AKST)
> From: Nicholas Mc Guire <hofrat@hofr.at>
> cc: Eli Zaretskii <eliz@gnu.org>, Joel Brobecker <brobecker@adacore.com>, 
>     gdb@sourceware.org
> 
> well its actually not that large - the patch to the core stuff is very
> small - more a set of bug-fixes than new stuff - and the changes to
> gdbserver are well encapsulated in seperate files.

How many non-comment, non-whitespace lines does it change?  If only a
few, then the patch could be accepted without a copyright assignment.

Failing that, perhaps you could describe where and what to change
without showing the actual code, and then someone else (who can assign
copyright) would implement that.  Ideas are not copyrightable, only
the actual implementation in code is.

Re: Our next GDB release (GDB version 6.8)

[Jim Blandy]

On Jan 25, 2008 4:53 PM, Joel Brobecker <brobecker@adacore.com> wrote:
> I propose we use a wiki page again. In fact, I was surprised to
> see that someone already created one. Should I thank Nick for that?

Using the wiki sounds like a great idea.

RE: Our next GDB release (GDB version 6.8)

[Pierre Muller]

  I would really like to have the 
call to __main fixed !
  This would allow to get consistent behavior
between linux and cygwin/mingw32 for the
'start' command as skip_prologue would
really go up to the first real instruction.

  Pedro proposed a patch for this,
http://sourceware.org/ml/gdb-patches/2007-10/msg00361.html
which is not perfect in the sense that it is
i386 specific, while this should be
processor independent.
  But supporting this for all compilers
might require much bigger changes,
like adding a processor independent layer to
skip_prologue, that would be able to
just call process_is_call (CORE_ADDR pc, char *func_name)
that would return pc if it is not a call instruction
or the CORE_ADDR after the call instruction if pc points to a call
instruction,
and func_name would return the function name if the call
points to a existing function (the second argument type
might also be a psymbol struct, or something similar...)
This could be used for __main _alloca, but probably also
for _mcount for executables containing profiling information.

  The reason this change is probably much bigger is 
that it would require to add a new processor_is_call function
to the tdep struct, and restructure the skip_prologue.

  Is it reasonable to hope for inclusion of this
patch before the branch?

Pierre Muller

PS: I would also like my small second patch about BINOP_INTDIV
http://sourceware.org/ml/gdb-patches/2008-01/msg00606.html

Re: Our next GDB release (GDB version 6.8)

[Pedro Alves]

Pierre Muller wrote:
>   I would really like to have the 
> call to __main fixed !

>   Is it reasonable to hope for inclusion of this
> patch before the branch?
> 

I'll post a much smaller patch later tonight.

-- 
Pedro Alves

Re: Our next GDB release (GDB version 6.8)

[Pedro Alves]

Joel Brobecker wrote:

> Opinions? Items that should be put on the list of things to finish
> for the release? Please send them here and I'll add them to the
> wiki. If a thread was already started, please post a link to it
> as well.
> 

I'd like to have gdbserver building on Windows CE again.  The remote
file transfer file support added a dependency on errno (*) that's
a no-no for Windows CE.  I'd like this discussed before the release
because it may require a small protocol change.
I'll start a thread on this later tonight.

(*) - Yes, Windows CE's runtime has no errno ...

-- 
Pedro Alves

Re: Our next GDB release (GDB version 6.8)

[Paul Koning]

>>>>> "Pedro" == Pedro Alves <pedro_alves@portugalmail.pt> writes:

 Pedro> I'd like to have gdbserver building on Windows CE again.  The
 Pedro> remote file transfer file support added a dependency on errno
 Pedro> (*) that's a no-no for Windows CE.  I'd like this discussed
 Pedro> before the release because it may require a small protocol
 Pedro> change.  I'll start a thread on this later tonight.

 Pedro> (*) - Yes, Windows CE's runtime has no errno ...

Just because the OS doesn't have a variable called "errno" doesn't
mean you can't have it in the protocol.  Clearly there are errors --
the protocol simply encodes those by their POSIX errno values.  If
your OS doesn't support those, you just need a mapping.  It doesn't
sound like something that needs, or justifies, a protocol change.

      paul

Re: Our next GDB release (GDB version 6.8)

[Pedro Alves]

Pedro Alves wrote:
> 
> I'd like to have gdbserver building on Windows CE again.  The remote
> file transfer file support added a dependency on errno (*) that's
> a no-no for Windows CE.  I'd like this discussed before the release
> because it may require a small protocol change.
> I'll start a thread on this later tonight.

For thread completeness, I've started the thread on the remote
protocol change (I should have said extension) here:

Small remote file transfer protocol adition
http://sourceware.org/ml/gdb/2008-01/msg00302.html

And proposed a patch that makes gdbserver build again on WinCE
(without remote protocol extensions) here:

[gdbserver] Make mingw32ce gdbserver build again
http://sourceware.org/ml/gdb-patches/2008-01/msg00838.html

I'd like that at least the later went into GDB6.8, so I've added a
link to the patch to the wiki.  Thanks Joel for putting the issue
there for me in the first place.

-- 
Pedro Alves

Re: Our next GDB release (GDB version 6.8)

[Thiago Jung Bauermann]

On Fri, 2008-01-25 at 16:53 -0800, Joel Brobecker wrote:
> Hello GDB enthusiasts!

Honk if you love GDB. :-)

> Opinions? Items that should be put on the list of things to finish
> for the release? Please send them here and I'll add them to the
> wiki.

I am really interested in having the few remaining DFP patches in before
the branch:

http://sourceware.org/ml/gdb-patches/2008-01/msg00584.html

http://sourceware.org/ml/gdb-patches/2008-01/msg00552.html

Regarding the last one, the basic idea seems to be approved, it's just
some implementation issues that need to be sorted out. I'll be providing
an updated patch very soon. After those two patches I can submit a NEWS
entry announcing DFP support.

It would also be good to have the ppc32 and ppc64 fixes to float
parameter passing included. These also seem to be on the verge of
getting in:

http://sourceware.org/ml/gdb-patches/2008-01/msg00623.html

http://sourceware.org/ml/gdb-patches/2008-01/msg00347.html

-- 
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center

Re: Our next GDB release (GDB version 6.8)

[Joel Brobecker]

> I would like us to start drawing a list of things that we'd like
> to include in that release. For one, I'd like to list the changes
> I submitted regarding Ada support, at least the ones that provide
> the most value.

It looks like at least some of the Ada-related features will require
some discussion. I don't want to hold the release for that, so
I won't list them.  There's always going to be the next release.

Thanks to everyone who sent their feedback. I am a little behind
right now, but I'll get to it soon.

-- 
Joel

Re: Our next GDB release (GDB version 6.8)

[Markus Deuling]

Hi Joel,

Joel Brobecker schrieb:
> Hello GDB enthusiasts!

> 
> Opinions? Items that should be put on the list of things to finish
> for the release? Please send them here and I'll add them to the
> wiki. If a thread was already started, please post a link to it
> as well.

I'd like to see this one in 6.8 -> http://sourceware.org/ml/gdb-patches/2008-01/msg00766.html

Regards,
Markus


-- 
  Markus Deuling
  GNU Toolchain for Linux on Cell BE
  deuling@de.ibm.com

Re: Our next GDB release (GDB version 6.8)

[Joel Brobecker]

Hi Markus,

> >Opinions? Items that should be put on the list of things to finish
> >for the release? Please send them here and I'll add them to the
> >wiki. If a thread was already started, please post a link to it
> >as well.
> 
> I'd like to see this one in 6.8 -> 
> http://sourceware.org/ml/gdb-patches/2008-01/msg00766.html

I have no objections to including this script in 6.8, but I don't
necessarily see it as being critical. This is a script that does
some sanity checking, right? I propose we don't hold the release
for it, but if you happen to get it checked in before the release,
then I will approve a request to port it to the 6.8 branch.

Sounds sensible to everyone?

-- 
Joel

Re: Our next GDB release (GDB version 6.8)

[Doug Evans]

On Jan 25, 2008 4:53 PM, Joel Brobecker <brobecker@adacore.com> wrote:
> I would like us to start drawing a list of things that we'd like
> to include in that release.

It would be nice to have a memory search feature in 6.8.
I've proposed http://sourceware.org/ml/gdb-patches/2008-01/msg00371.html

Re: Our next GDB release (GDB version 6.8)

[Joel Brobecker]

> It would be nice to have a memory search feature in 6.8.
> I've proposed http://sourceware.org/ml/gdb-patches/2008-01/msg00371.html

This is a new feature that you are suggesting, so I propose that we
don't hold up the release for it. That doesn't mean that it won't
make 6.8, just that if things get delayed past the branch-point,
we'll only have it for 6.9 (which is only 6 months later).

-- 
Joel

Re: Our next GDB release (GDB version 6.8)

[Vladimir Prus]

Joel Brobecker wrote:

> Hello GDB enthusiasts!
> 
> The schedule on the GDB website shows that we were planning on
> making a new GDB release (GDB version 6.8) soon: Branch creation
> on Feb 5th, and a then an official release a month later.
> Looks like it's going to be tight to make these dates, but
> I don't think it's a problem.
> 
> I would like us to start drawing a list of things that we'd like
> to include in that release. For one, I'd like to list the changes
> I submitted regarding Ada support, at least the ones that provide
> the most value. Maybe I'll also find some time to work on something
> we briefly discussed a few years back regarding the README file, and
> maybe think about the NEWS file too.  That's not critical though,
> just making the release slightly more labor intensive.
> 
> I propose we use a wiki page again. In fact, I was surprised to
> see that someone already created one. Should I thank Nick for that?
> 
> Opinions? Items that should be put on the list of things to finish
> for the release? Please send them here and I'll add them to the
> wiki. If a thread was already started, please post a link to it
> as well.

I would like these two patches to go in:

        http://sourceware.org/ml/gdb-patches/2008-01/msg00629.html
        http://sourceware.org/ml/gdb-patches/2008-01/msg00632.html

They, together, fix a bug where gdb produces a totally bogus MI
response.

- Volodya

Re: Our next GDB release (GDB version 6.8)

[Joel Brobecker]

> I would like these two patches to go in:
> 
>         http://sourceware.org/ml/gdb-patches/2008-01/msg00629.html
>         http://sourceware.org/ml/gdb-patches/2008-01/msg00632.html
> 
> They, together, fix a bug where gdb produces a totally bogus MI
> response.

Entries added.

-- 
Joel