From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: GDB Discussion Subject: GDB 5.1 TODO list Date: Tue, 01 Aug 2000 18:50:00 -0000 Message-id: <39877E58.2828D2B5@cygnus.com> X-SW-Source: 2000-08/msg00008.html 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 $(
_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" To: 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 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 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 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 > > 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 To: Eli Zaretskii 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 > > > > 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 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 > > 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 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 To: Andrew Cagney , GDB Discussion 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 To: GDB Discussion Cc: Fernando Nasser , Scott Bambrough , Michael Snyder , GDB Patches Mail List 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 To: Andrew Cagney , GDB Discussion Cc: GDB Patches Mail List 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> 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 To: Kevin Buettner Cc: Andrew Cagney , GDB Discussion , GDB Patches Mail List Subject: Re: RFA: Testsuite patches... Date: Wed, 02 Aug 2000 09:45:00 -0000 Message-id: 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 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