GDB 5.1 TODO list

[Andrew Cagney <ac131313@cygnus.com>]

Ok,

So here is a first cut at the things that are really on the 5.1 TODO
list.  In previous discussions it has been suggested that for each
release a small number of changes be identifed and completed (of course
everyone is activly encouraged to also work on any other TODO or
non-TODO items :-)

The other thing not mentioned in the below is that 5.1 also have a
slightly better organized release cycle.  I'd suggest something like:

	o	TODO list finished

	o	Maintainers publish current
		acceptable test results

	o	Branch

	o	Maintainers re-check
		their test results on branch.
		(And there be at least a week for this).

Having the patch/bug database and a test framework up would also be
nice.

	enjoy,
		Andrew


                        GDB 5.1 - Fixes
                        ===============

Below is a list of problems identified during the GDB 5.0 release
cycle.  People hope to have these problems fixed in 5.1.

--

RFD: infrun.c: No bpstat_stop_status call after proceed over break?
http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00665.html

GDB misses watchpoint triggers after proceeding over a breakpoint on
x86 targets.

--

x86 linux GDB and SIGALRM (???)
http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00803.html

This problem has been fixed, but a regression test still needs to be
added to the testsuite:
http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00309.html

Mark

--

Can't build IRIX -> arm GDB.
http://sourceware.cygnus.com/ml/gdb-patches/2000-04/msg00356.html

David Whedon writes:
> Now I'm building for an embedded arm target.  If there is a way of turning
> remote-rdi off, I couldn't find it. It looks like it gets built by default
> in gdb/configure.tgt(line 58) Anyway, the build dies in
> gdb/rdi-share/unixcomm.c.  SERPORT1 et. al. never get defined because we
> aren't one of the architectures supported.

--

Problem with weak functions
http://sourceware.cygnus.com/ml/gdb/2000-05/msg00060.html

Dan Nicolaescu writes:
> It seems that gdb-4.95.1  does not display correctly the function when
> stoping in weak functions. 
> 
> It stops in a function that is defined as weak, not in the function
> that is actualy run... 

--

GDB 5.0 doesn't work on Linux/SPARC

--

parse.c:build_parse() has a buffer overrun.

--

                GDB 5.1 - New features
                ======================

The following new features should be included in 5.1.

--

Enable MI by default.  Old code can be deleted after 5.1 is out.

--

Pascal (Pierre Muller, David Taylor)

Pierre Muller has contributed patches for adding Pascal Language
support to GDB.

2 pascal language patches inserted in database
http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00521.html

Indent -gnu ?
http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00496.html

--

Java (Anthony Green, David Taylor)

Anthony Green has a number of Java patches that did not make it into
the 5.0 release.  The first two are in cvs now, but the third needs
some fixing up before it can go in.

Patch: java tests
http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00512.html

Patch: java booleans
http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00515.html

Patch: handle N_MAIN stab
http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00527.html

--

[Comming...]

Modify gdb to work correctly with Pascal.

--

Revised UDP support (was: Re: [Fwd: [patch] UDP transport support])
http://sourceware.cygnus.com/ml/gdb-patches/2000-04/msg00000.html

(Broken) support for GDB's remote protocol across UDP is to be
included in the follow-on release.

It should be noted that UDP can only work when the [Gg] packet fits in
a single UDP packet.

There is also much debate over the merit of this.

--

                GDB 5.1 - Cleanups
                ==================

The following code cleanups will hopefully be applied to GDB 5.1.

--

Delete macro TARGET_BYTE_ORDER_SELECTABLE.

Patches in the database.

--

Fix copyright notices.

Turns out that ``1998-2000'' isn't considered valid :-(

http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00467.html

--

Purge PARAMS.

Eliminate all uses of PARAMS in GDB's source code.

--

printcmd.c (print_address_numeric):

NOTE: This assumes that the significant address information is kept in
the least significant bits of ADDR - the upper bits were either zero
or sign extended.  Should ADDRESS_TO_POINTER() or some
ADDRESS_TO_PRINTABLE() be used to do the conversion?

--

Compiler warnings.

Eliminate all warnings for at least one host/target for the flags:
-Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses
-Wpointer-arith -Wuninitialized

--


Follow through `make check' with --enable-shared.

When the srcware tree is configured with --enable-shared, the `expect'
program won't run properly.  Jim Wilson found out gdb has a local hack
to set LD_LIBRARY_PATH, but, AFAIK, no other project has been hacked
similarly.

http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00845.html

--

                GDB 5.2 - Fixes
                ===============

--

                GDB 5.2 - New features
                ======================

--

                GDB 5.2 - Cleanups
                ==================

The following cleanups have been identified as part of GDB 5.2.

--

Eliminate more compiler warnings.

--

Restructure gdb directory tree so that it avoids any 8.3 and 14
filename problems.

--

Convert GDB build process to AUTOMAKE.

See also sub-directory configure below.

The current convention is (kind of) to use $(<header>_h) in all
dependency lists.  It isn't done in a consistent way.

--
From niraj@zumanetworks.com Tue Aug 01 21:19:00 2000
From: "niraj gupta" <niraj@zumanetworks.com>
To: <gdb@sources.redhat.com>
Subject: support for remote/serial tcp not there linux host (maybe others too)
Date: Tue, 01 Aug 2000 21:19:00 -0000
Message-id: <000001bffc38$2d418520$d301a8c0@internal.nbase.com>
X-SW-Source: 2000-08/msg00009.html
Content-length: 264

looks like this happened in gdb/Makefile.in version 1.39
maybe following is the change which caused it

in 1.38 it was
SER_HARDWIRE = @SER_HARDWIRE@


in 1.39 it is
SER_HARDWIRE = ser-unix.o ser-pipe.o

i would like to see ser-tcp.o back in Makefile.in

THX
niraj
From kettenis@wins.uva.nl Tue Aug 01 21:43:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: ac131313@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: GDB 5.1 TODO list
Date: Tue, 01 Aug 2000 21:43:00 -0000
Message-id: <200008020442.e724gwr08967@delius.kettenis.local>
References: <39877E58.2828D2B5@cygnus.com>
X-SW-Source: 2000-08/msg00010.html
Content-length: 1246

   Date: Wed, 02 Aug 2000 11:50:16 +1000
   From: Andrew Cagney <ac131313@cygnus.com>

   Ok,

   So here is a first cut at the things that are really on the 5.1 TODO
   list.  In previous discussions it has been suggested that for each
   release a small number of changes be identifed and completed (of course
   everyone is activly encouraged to also work on any other TODO or
   non-TODO items :-)

There are two things that I consider release-critical for Linux/x86:

* Thread support.  Right now, as soon as a thread finishes and exits,
  you're hosed.  This problem is reported once a week or so.

* Bug with rerunning programs with breakpoints in shared libs.  Citing
  what I reported in response to your query for GDB 5.0.1:

    IMHO, releasing 5.0.1 is only worth the trouble if it fixes the really
    annoying problem with rerunning programs with breakpoints in shared libs:

       http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00230.html

    This patch is kind of a stopgap, but I've failed to come up with
    something better, and no-one else seems to be interested in solving
    this :-(.

  This problem probably affects all platforms with support for shared
  libraries.

Shall I add these to the TODO list?

Mark
From eliz@delorie.com Wed Aug 02 00:52:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: ac131313@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: GDB 5.1 TODO list
Date: Wed, 02 Aug 2000 00:52:00 -0000
Message-id: <200008020752.DAA25347@indy.delorie.com>
References: <39877E58.2828D2B5@cygnus.com>
X-SW-Source: 2000-08/msg00011.html
Content-length: 533

> Date: Wed, 02 Aug 2000 11:50:16 +1000
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> Eliminate all warnings for at least one host/target for the flags:
> -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses
> -Wpointer-arith -Wuninitialized

I tried to do this during the release cycle of 5.0, but one thing that
stopped me was the massive amount of warnings when compiling Readline.
It kinda makes the whole exercise futile...

Is it possible to reset the warning switches to a lesser level for
Readline alone?
From ac131313@cygnus.com Wed Aug 02 01:50:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb@sourceware.cygnus.com
Subject: Re: GDB 5.1 TODO list
Date: Wed, 02 Aug 2000 01:50:00 -0000
Message-id: <3987E0CB.32877298@cygnus.com>
References: <39877E58.2828D2B5@cygnus.com> <200008020752.DAA25347@indy.delorie.com>
X-SW-Source: 2000-08/msg00012.html
Content-length: 1010

Eli Zaretskii wrote:
> 
> > Date: Wed, 02 Aug 2000 11:50:16 +1000
> > From: Andrew Cagney <ac131313@cygnus.com>
> >
> > Eliminate all warnings for at least one host/target for the flags:
> > -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses
> > -Wpointer-arith -Wuninitialized
> 
> I tried to do this during the release cycle of 5.0, but one thing that
> stopped me was the massive amount of warnings when compiling Readline.
> It kinda makes the whole exercise futile...

Try configuring with

--enable-build-warnings=-Wimplicit,-Wreturn-type,-Wcomment,-Wtrigraphs,-Wformat,-Wparentheses,
-Wpointer-arith,-Werror

The directories where people are trying to flush warnings recognize this
configure option (GDB, BFD, ...).  The -Werror is to make certain
nothing is missed :-)

I had most targets building with -Wuninitialized but with the recent K&R
to ISO things have taken a hit.  I'd suggest trying just -Werror for
your target and then build up to something stronger.

	enjoy,
		Andrew
From eliz@delorie.com Wed Aug 02 03:17:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: ac131313@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: GDB 5.1 TODO list
Date: Wed, 02 Aug 2000 03:17:00 -0000
Message-id: <200008021016.GAA25482@indy.delorie.com>
References: <39877E58.2828D2B5@cygnus.com> <200008020752.DAA25347@indy.delorie.com> <3987E0CB.32877298@cygnus.com>
X-SW-Source: 2000-08/msg00013.html
Content-length: 584

>  Date: Wed, 02 Aug 2000 18:50:19 +1000
>  From: Andrew Cagney <ac131313@cygnus.com>
> 
>  Try configuring with
>     --enable-build-warnings=-Wimplicit,-Wreturn-type,-Wcomment,-Wtrigraphs,-Wformat,-Wparentheses,
>  -Wpointer-arith,-Werror

The DJGPP port is already configured with
  --enable-build-warnings=-Wimplicit,-Wcomment,-Wformat,-Wparentheses,
    -Wpointer-arith

(See config/djgpp/djconfig.sh.)  I'll try to add others when I get to
it.  Last time I tried, there were too many warnings from sources that
aren't specific to the DJGPP target, and I *hate* to see warnings.
From richard@brainstorm.co.uk Wed Aug 02 03:29:00 2000
From: richard@brainstorm.co.uk
To: ac131313@cygnus.com
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: GDB 5.1 TODO list
Date: Wed, 02 Aug 2000 03:29:00 -0000
Message-id: <10008021015.AA03688@tiptree.brainstorm.co.uk>
References: <39877E58.2828D2B5@cygnus.com>
X-SW-Source: 2000-08/msg00014.html
Content-length: 161

On Wed, 02 Aug 2000 11:50:16 +1000, ac131313@cygnus.com wrote:
> GDB 5.1 - New features
> ======================

Shouldn't Objective-C support be on this list?
From dyp@perchine.com Wed Aug 02 03:37:00 2000
From: Denis Perchine <dyp@perchine.com>
To: Andrew Cagney <ac131313@cygnus.com>, GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: GDB 5.1 TODO list
Date: Wed, 02 Aug 2000 03:37:00 -0000
Message-id: <00080217420101.00568@dyp.perchine.com>
References: <39877E58.2828D2B5@cygnus.com>
X-SW-Source: 2000-08/msg00015.html
Content-length: 612

> So here is a first cut at the things that are really on the 5.1 TODO
> list.  In previous discussions it has been suggested that for each
> release a small number of changes be identifed and completed (of course
> everyone is activly encouraged to also work on any other TODO or
> non-TODO items :-)

Is threads on Linux worked properly?
In 5.0 there was real mess with them. It was impossible to debug MT programs.

-- 
Sincerely Yours,
Denis Perchine

----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------
From ac131313@cygnus.com Wed Aug 02 04:55:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Cc: Fernando Nasser <fnasser@cygnus.com>, Scott Bambrough <scottb@netwinder.org>, Michael Snyder <msnyder@cygnus.com>, GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Re: RFA: Testsuite patches...
Date: Wed, 02 Aug 2000 04:55:00 -0000
Message-id: <39880C36.A2DA09D7@cygnus.com>
References: <39803B5C.9C31BB15@netwinder.org> <3980469B.E0BD7ED2@cygnus.com> <3980D60D.6EAB40A8@cygnus.com>
X-SW-Source: 2000-08/msg00016.html
Content-length: 1472

[suggest following up to gdb@sourceware - not patch specific]

Andrew Cagney wrote:
> 
> Um, careful here.

Double Um, I should be more careful, sorry :-(

> I don't think the question to ask is ``who will fix the failures''.
> Rather, I think people should be asking  ``does the test check correct
> functionality''?
> 
> If the test is correct and applicable to more than just HP then I think
> it should be enabled.  If it adds to the number of failures for certain
> targets then ``oops'' :-)  I'd assume the relevant maintainers would
> simply append this to their list of known problems.
> 
> Perhaphs post something like a transcript (assuming they are not to
> large) of each test so people can see them in action.
> 
> As a generalization, GDB desperatly needs more tests.

Its been pointed out I've got the current policy wrong.  There was a
debate (internal to Cygnus though :-() but the policy didn't get changed
- in general a testsuite shouldn't go in unless it is accompanied by a
fix.

From the above you can tell that I think this is too stringent.  I think
GDB should be accepting tests (provided that they are rigiously
examined) even when they add failures - just as long as the failures
examine real bugs.  I think this also better reflects what really goes
on.

BTW, as twist too all this, HP and Cygnus were quietly contributing
tests (call-*-st.exp in particular) which, at least initially, only
passed on HP platforms.

thoughs?

	enjoy,
		Andrew
From kevinb@cygnus.com Wed Aug 02 09:37:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>, GDB Discussion <gdb@sourceware.cygnus.com>
Cc: GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Re: RFA: Testsuite patches...
Date: Wed, 02 Aug 2000 09:37:00 -0000
Message-id: <1000802163645.ZM23394@ocotillo.lan>
References: <39803B5C.9C31BB15@netwinder.org> <3980469B.E0BD7ED2@cygnus.com> <3980D60D.6EAB40A8@cygnus.com> <39880C36.A2DA09D7@cygnus.com> <ac131313@cygnus.com>
X-SW-Source: 2000-08/msg00017.html
Content-length: 796

On Aug 2,  9:55pm, Andrew Cagney wrote:

> I think GDB should be accepting tests (provided that they are
> rigiously examined) even when they add failures - just as long as
> the failures examine real bugs.  I think this also better reflects
> what really goes on.

I agree.

If we make "no new failures" the criteria for whether a test is added
to the testsuite or not, then it seems to me that we'll end up adding
very few new tests just because it's so difficult for any one person
to test on all affected targets.  (And it really doesn't work to
post a patch and expect everyone affected to try it.)

It makes sense to me to spread the workload by adding a test and then
expecting the various maintainers to make sure that the test passes
(or gets suitably tweaked) for their targets.

Kevin
From dberlin@redhat.com Wed Aug 02 09:45:00 2000
From: Daniel Berlin <dberlin@redhat.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Andrew Cagney <ac131313@cygnus.com>, GDB Discussion <gdb@sourceware.cygnus.com>, GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Re: RFA: Testsuite patches...
Date: Wed, 02 Aug 2000 09:45:00 -0000
Message-id: <m31z07bojh.fsf@dan2.cygnus.com>
References: <39803B5C.9C31BB15@netwinder.org> <3980469B.E0BD7ED2@cygnus.com> <3980D60D.6EAB40A8@cygnus.com> <39880C36.A2DA09D7@cygnus.com> <1000802163645.ZM23394@ocotillo.lan>
X-SW-Source: 2000-08/msg00018.html
Content-length: 1631

Kevin Buettner <kevinb@cygnus.com> writes:

> On Aug 2,  9:55pm, Andrew Cagney wrote:
> 
> > I think GDB should be accepting tests (provided that they are
> > rigiously examined) even when they add failures - just as long as
> > the failures examine real bugs.  I think this also better reflects
> > what really goes on.
> 
> I agree.
> 
> If we make "no new failures" the criteria for whether a test is added
> to the testsuite or not, then it seems to me that we'll end up adding
> very few new tests just because it's so difficult for any one person
> to test on all affected targets.  (And it really doesn't work to
> post a patch and expect everyone affected to try it.)
> 
> It makes sense to me to spread the workload by adding a test and then
> expecting the various maintainers to make sure that the test passes
> (or gets suitably tweaked) for their targets.
> 
> Kevin

This seems like a better idea.

In fact, I propose the following, or something like it:

We accept all new tests people are willing to contribute, whether GDB
passes them or not, on any platform (assuming the test itself is
showing a problem with GDB, or something that should eventually work
in GDB, like say, virtual function calling).

We have a seperate directory in the testsuite for tests that nobody
has any idea whether it will pass on all platforms or not, or whether
GDB can do that yet or not.

That way, even if you XFAIL'd the test (so people didn't bitch about
the failures), at least I could look in that test results for that directory when I wanted to know what should be
working, but isn't, etc.

Or maybe i'm just babbling.
--Dan