From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii To: Mark Kettenis Cc: gdb@sourceware.cygnus.com, msnyder@cygnus.com Subject: Re: Disabling lin-thread.c module Date: Tue, 11 Apr 2000 04:16:00 -0000 Message-id: <200004111116.HAA03833@indy.delorie.com> References: <200004101237.OAA29849@landau.wins.uva.nl> X-SW-Source: 2000-04/msg00038.html > Since glibc-2.1.3 was released with a bogus definition for > prfpregset_t (at least for Linux/i386[1]), we'll have to take some > measures to make sure that GDB-5.0 will work with glibc-2.1.3. > > I see three possibilities: > > 1. Disable the lin-thread.c module by default, and provide a switch > --enable-thread-db to enable the module, such that people can build > the module if the headers have been fixed (for example when > glibc-2.1.4 has been installed). > > 2. Provide the same switch, but use an autoconf test to check whether > the prfpregset_t type is broken, and enable the module based on the > result of that test. > > 3. Use an autoconf test to check whether the prfpregset_t type is > broken, and let GDB work around it. > > I'm inclined to implement option 3, since that means that the > lin-thread.c code will be somewhat more thoroughly tested, but there > may be some drawbacks: I suggest option 3, but I also suggest to activate that autoconf test and the entire feature only if the package is configured with --enable-thread-db. I think this is the right approach for an experimental/dangerous feature which wasn't tested well enough. >From kettenis@wins.uva.nl Tue Apr 11 04:48:00 2000 From: Mark Kettenis To: eliz@is.elta.co.il Cc: gdb@sourceware.cygnus.com, msnyder@cygnus.com Subject: Re: Disabling lin-thread.c module Date: Tue, 11 Apr 2000 04:48:00 -0000 Message-id: <200004111148.NAA00978@landau.wins.uva.nl> References: <200004101237.OAA29849@landau.wins.uva.nl> <200004111116.HAA03833@indy.delorie.com> X-SW-Source: 2000-04/msg00039.html Content-length: 1043 Date: Tue, 11 Apr 2000 07:16:40 -0400 (EDT) From: Eli Zaretskii I suggest option 3, but I also suggest to activate that autoconf test and the entire feature only if the package is configured with --enable-thread-db. I think this is the right approach for an experimental/dangerous feature which wasn't tested well enough. Well, the alternative to the libthread_db assisted threads debugging code isn't that much better tested. In both cases, the threads-related tests in the testsuite are passed. I haven't seen any evidence of people doing more thread-related testing with gdb snapshots on Linux/i386. Anyway, the --enable-thread-db option is completely orthogonal to the autoconf test. I'd really like to see the libthread_db assisted code being used, otherwise we'll never learn about problems with it. Looks like Michael Snyder feels the same way. But if there are more people who think disabling the code by default and adding --enable-thread-db is a good idea, I'll be happy to add it. Mark >From hjl@lucon.org Tue Apr 11 07:53:00 2000 From: "H . J . Lu" To: Mark Kettenis Cc: eliz@is.elta.co.il, gdb@sourceware.cygnus.com, msnyder@cygnus.com Subject: Re: Disabling lin-thread.c module Date: Tue, 11 Apr 2000 07:53:00 -0000 Message-id: <20000411075259.B4776@lucon.org> References: <200004101237.OAA29849@landau.wins.uva.nl> <200004111116.HAA03833@indy.delorie.com> <200004111148.NAA00978@landau.wins.uva.nl> X-SW-Source: 2000-04/msg00040.html Content-length: 1427 On Tue, Apr 11, 2000 at 01:48:46PM +0200, Mark Kettenis wrote: > Date: Tue, 11 Apr 2000 07:16:40 -0400 (EDT) > From: Eli Zaretskii > > I suggest option 3, but I also suggest to activate that autoconf test > and the entire feature only if the package is configured with > --enable-thread-db. I think this is the right approach for an > experimental/dangerous feature which wasn't tested well enough. > > Well, the alternative to the libthread_db assisted threads debugging > code isn't that much better tested. In both cases, the > threads-related tests in the testsuite are passed. I haven't seen any > evidence of people doing more thread-related testing with gdb > snapshots on Linux/i386. > > Anyway, the --enable-thread-db option is completely orthogonal to the > autoconf test. I'd really like to see the libthread_db assisted code > being used, otherwise we'll never learn about problems with it. > Looks like Michael Snyder feels the same way. But if there are more > people who think disabling the code by default and adding > --enable-thread-db is a good idea, I'll be happy to add it. People are using gdb for real work. They shouldn't second guess about gdb. I vote for disable libthread_db by default for 5.0 and turn it on in CVS. People who use the public release won't get libthread_db by default. But they will test libthread_db if they use CVS or snapshot. H.J. >From jlarmour@redhat.co.uk Tue Apr 11 08:10:00 2000 From: Jonathan Larmour To: gdb@sourceware.cygnus.com Subject: gdb weekly snapshots Date: Tue, 11 Apr 2000 08:10:00 -0000 Message-id: <38F3407B.774A55CE@redhat.co.uk> X-SW-Source: 2000-04/msg00041.html Content-length: 731 The "weekly" snapshots haven't happened for a while - March 13th specifically. If they are done by cron jobs, perhaps they need some kicking? I know the snapshots that include dejagnu are done more frequently, but I'd prefer to point people at smaller downloads if they aren't going to run the testsuite. If it's considered better just to drop the non-dejagnu snapshots, can those instead be made the gdb.tar.bz2/insight.tar.bz2 hard links in whatever the script is (those names make for easier URLs to point people at), and remove the old snapshots please? Thanks, Jifl -- Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 (1223) 728762 "Plan to be spontaneous tomorrow." || These opinions are all my own fault >From scottb@netwinder.org Tue Apr 11 08:19:00 2000 From: Scott Bambrough To: GDB Mailing List Subject: Documentation build problem in GDB 5 branch... Date: Tue, 11 Apr 2000 08:19:00 -0000 Message-id: <38F341AF.B615A276@netwinder.org> X-SW-Source: 2000-04/msg00042.html Content-length: 1293 I get the following problem doing a `make info` in the doc directory of my gdb build tree in the branch. It seems to work fine in the main line. I know nothing about info so I'm punting... Scott makeinfo -o gdbint.info ../../../src/gdb/doc/gdbint.texinfo ../../../src/gdb/doc/gdbint.texinfo:1700: Cross reference to nonexistent node `Using Different Target and Host Data Representations'. ../../../src/gdb/doc/gdbint.texinfo:1696: Cross reference to nonexistent node `Using Different Target and Host Data Representations'. ../../../src/gdb/doc/gdbint.texinfo:1692: Cross reference to nonexistent node `Using Different Target and Host Data Representations'. ../../../src/gdb/doc/gdbint.texinfo:1688: Cross reference to nonexistent node `Using Different Target and Host Data Representations'. ../../../src/gdb/doc/gdbint.texinfo:1684: Cross reference to nonexistent node `Using Different Target and Host Data Representations'. ../../../src/gdb/doc/gdbint.texinfo:1680: Cross reference to nonexistent node `Using Different Target and Host Data Representations'. makeinfo: Removing output file `gdbint.info' due to errors; use --force to preserve. make: *** [gdbint.info] Error 2 -- Scott Bambrough - Software Engineer REBEL.COM http://www.rebel.com NetWinder http://www.netwinder.org >From msnyder@cygnus.com Tue Apr 11 10:26:00 2000 From: Michael Snyder To: Mark Kettenis Cc: eliz@is.elta.co.il, gdb@sourceware.cygnus.com Subject: Re: Disabling lin-thread.c module Date: Tue, 11 Apr 2000 10:26:00 -0000 Message-id: <38F35FE5.660@cygnus.com> References: <200004101237.OAA29849@landau.wins.uva.nl> <200004111116.HAA03833@indy.delorie.com> <200004111148.NAA00978@landau.wins.uva.nl> X-SW-Source: 2000-04/msg00043.html Content-length: 1269 Mark Kettenis wrote: > > Date: Tue, 11 Apr 2000 07:16:40 -0400 (EDT) > From: Eli Zaretskii > > I suggest option 3, but I also suggest to activate that autoconf test > and the entire feature only if the package is configured with > --enable-thread-db. I think this is the right approach for an > experimental/dangerous feature which wasn't tested well enough. > > Well, the alternative to the libthread_db assisted threads debugging > code isn't that much better tested. In both cases, the > threads-related tests in the testsuite are passed. I haven't seen any > evidence of people doing more thread-related testing with gdb > snapshots on Linux/i386. > > Anyway, the --enable-thread-db option is completely orthogonal to the > autoconf test. I'd really like to see the libthread_db assisted code > being used, otherwise we'll never learn about problems with it. > Looks like Michael Snyder feels the same way. Moreover, we HAVE to start using it, because the older method simply isn't going to continue working indefinitely, as LIBC development moves forward. The thread-db method was developed for a reason: it helps to separate GDB from dependancy on knowledge of the internal details of implementation in libthread. >From eliz@delorie.com Tue Apr 11 11:55:00 2000 From: Eli Zaretskii To: gdb@sourceware.cygnus.com Subject: Completing for file names Date: Tue, 11 Apr 2000 11:55:00 -0000 Message-id: <200004111855.OAA04253@indy.delorie.com> X-SW-Source: 2000-04/msg00044.html Content-length: 189 I think the following GDB commands should use the file-name completer function when the user presses a TAB: attach make set history filename set remotelogfile shell Comments? >From jtc@redback.com Tue Apr 11 12:04:00 2000 From: jtc@redback.com (J.T. Conklin) To: Eli Zaretskii Cc: gdb@sourceware.cygnus.com Subject: Re: Completing for file names Date: Tue, 11 Apr 2000 12:04:00 -0000 Message-id: <5mhfd8a28r.fsf@jtc.redback.com> References: <200004111855.OAA04253@indy.delorie.com> X-SW-Source: 2000-04/msg00045.html Content-length: 386 >>>>> "Eli" == Eli Zaretskii writes: Eli> I think the following GDB commands should use the file-name completer Eli> function when the user presses a TAB: Eli> Eli> attach Eli> make Eli> set history filename Eli> set remotelogfile Eli> shell Eli> Comments? Doesn't attach take a process id, not a file? --jtc -- J.T. Conklin RedBack Networks >From jimb@zwingli.cygnus.com Tue Apr 11 15:30:00 2000 From: Jim Blandy To: Daniel Berlin Cc: gdb@sourceware.cygnus.com Subject: Re: Reducing memory usage Date: Tue, 11 Apr 2000 15:30:00 -0000 Message-id: References: X-SW-Source: 2000-04/msg00046.html Content-length: 1633 > For starters, we don't try to not duplicate type info when reading dwarf2. > I've fixed this. > Doing this takes gdb, with all of it's symbols read in, from this: > Statistics for '/usr/local/gdb/src/gdb/gdb': > Number of "stab" symbols read: 290212 > Number of "minimal" symbols read: 10600 > Number of "partial" symbols read: 160442 > Number of "full" symbols read: 237611 > Number of "types" defined: 129044 > Space used by a.out string tables: 974998 > Total memory used for psymbol obstack: 8017943 > Total memory used for psymbol cache: 948776 > Total memory used for symbol obstack: 24542604 > Total memory used for type obstack: 19411848 > > to this: > > Statistics for '/usr/local/gdb/src/gdb/./gdb': > Number of "stab" symbols read: 290212 > Number of "minimal" symbols read: 10600 > Number of "partial" symbols read: 160442 > Number of "full" symbols read: 155649 > Number of "types" defined: 105366 > Space used by a.out string tables: 974998 > Total memory used for psymbol obstack: 8017943 > Total memory used for psymbol cache: 948776 > Total memory used for symbol obstack: 18510936 > Total memory used for type obstack: 12585708 > > A savings of about 13 meg (and in percentages, we save 45% of the type > obstack, 25% of the symbol stack). > > This only helps for dwarf2, stabs and whatnot were already doing something > similar. > > I used the hashtable implementation libiberty now provides, rather than > introduce yet another gdb hashtable type. > > Not too shabby, methinks. Yep --- pretty darn good, actually. If you send me the patches, I'll look them over. >From ac131313@cygnus.com Tue Apr 11 17:17:00 2000 From: Andrew Cagney To: Scott Bambrough Cc: GDB Mailing List Subject: Re: Documentation build problem in GDB 5 branch... Date: Tue, 11 Apr 2000 17:17:00 -0000 Message-id: <38F3BFF6.6C575BE8@cygnus.com> References: <38F341AF.B615A276@netwinder.org> X-SW-Source: 2000-04/msg00047.html Content-length: 1387 Scott Bambrough wrote: > > I get the following problem doing a `make info` in the doc directory of my gdb > build tree in the branch. It seems to work fine in the main line. I know > nothing about info so I'm punting... > > Scott > > makeinfo -o gdbint.info ../../../src/gdb/doc/gdbint.texinfo > ../../../src/gdb/doc/gdbint.texinfo:1700: Cross reference to nonexistent > node `Using Different Target and Host Data Representations'. > ../../../src/gdb/doc/gdbint.texinfo:1696: Cross reference to nonexistent > node `Using Different Target and Host Data Representations'. > ../../../src/gdb/doc/gdbint.texinfo:1692: Cross reference to nonexistent > node `Using Different Target and Host Data Representations'. > ../../../src/gdb/doc/gdbint.texinfo:1688: Cross reference to nonexistent > node `Using Different Target and Host Data Representations'. > ../../../src/gdb/doc/gdbint.texinfo:1684: Cross reference to nonexistent > node `Using Different Target and Host Data Representations'. > ../../../src/gdb/doc/gdbint.texinfo:1680: Cross reference to nonexistent > node `Using Different Target and Host Data Representations'. > makeinfo: Removing output file `gdbint.info' due to errors; use --force to > preserve. > make: *** [gdbint.info] Error 2 I know (its hard to miss it - it stops the snapshots). JimB cooked up a patch in devo and I'm now importing it to the branch. Andrew >From ac131313@cygnus.com Tue Apr 11 23:02:00 2000 From: Andrew Cagney To: Jonathan Larmour Cc: gdb@sourceware.cygnus.com Subject: Re: gdb weekly snapshots Date: Tue, 11 Apr 2000 23:02:00 -0000 Message-id: <38F410D4.63F2C883@cygnus.com> References: <38F3407B.774A55CE@redhat.co.uk> X-SW-Source: 2000-04/msg00048.html Content-length: 1436 Jonathan Larmour wrote: > > The "weekly" snapshots haven't happened for a while - March 13th > specifically. If they are done by cron jobs, perhaps they need some > kicking? I know the snapshots that include dejagnu are done more > frequently, but I'd prefer to point people at smaller downloads if they > aren't going to run the testsuite. FYI, the last few days snapshots have been barfing (build problem) but beyond that they appear to be working ok. I'm currently pushing through a snapshot by hand. I suspect you've been fooled by the old dejagnu and gdb-only snapshots that are still lying around, time to delete. > If it's considered better just to drop the non-dejagnu snapshots, can those > instead be made the gdb.tar.bz2/insight.tar.bz2 hard links in whatever the > script is (those names make for easier URLs to point people at), and remove > the old snapshots please? At present gdb+dejagnu.tar.bz2 and insight+dejagnu.tar.bz2 snapshots are being created. The names best reflect what is really in the archive. Also of interest is the weekly *-CVS-* file. It contains a full CVS checkout (although right now it is a checkout of the GDB-5.0 branch). With respect to pointing gdb.tar.bz2 -> gdb+dejagnu.tar.bz2. The mirror sites probably won't like it. Like a separate gdb.tar.bz2 archive (which is what I was doing) it would just increase the amount of mirror data being shipped out each night. enjoy, Andrew >From eliz@delorie.com Wed Apr 12 01:25:00 2000 From: Eli Zaretskii To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: Completing for file names Date: Wed, 12 Apr 2000 01:25:00 -0000 Message-id: <200004120825.EAA05112@indy.delorie.com> References: <200004111855.OAA04253@indy.delorie.com> <5mhfd8a28r.fsf@jtc.redback.com> X-SW-Source: 2000-04/msg00049.html Content-length: 96 > Doesn't attach take a process id, not a file? According to the docs, it can take either one. >From eliz@delorie.com Wed Apr 12 01:27:00 2000 From: Eli Zaretskii To: gdb@sourceware.cygnus.com Subject: Re: Completing for file names Date: Wed, 12 Apr 2000 01:27:00 -0000 Message-id: <200004120827.EAA05121@indy.delorie.com> References: <200004111855.OAA04253@indy.delorie.com> X-SW-Source: 2000-04/msg00050.html Content-length: 229 > I think the following GDB commands should use the file-name completer > function when the user presses a TAB: > > attach > make > set history filename > set remotelogfile > shell Sorry, I forgot another one: "run". >From rearnsha@arm.com Wed Apr 12 04:00:00 2000 From: Richard Earnshaw To: gdb@sourceware.cygnus.com Cc: rearnsha@arm.com Subject: Finding runtest Date: Wed, 12 Apr 2000 04:00:00 -0000 Message-id: <200004121100.MAA17801@cam-mail2.cambridge.arm.com> X-SW-Source: 2000-04/msg00051.html Content-length: 789 gdb comes with dejagnu as part of the distribution (to ensure we use one with the correct features). Most of the time, the make system will pick this up automatically and use it in preference to any version that is installed on the path. Unfortunately, this is not the case when checking dejagnu itself. In this case, it will only work using a version that has already been installed. The effect of this is that "make check" will fail when trying to check dejagnu if dejagnu has not been previously installed on the path. I'm not entirely convinced that it is correct for a test program to be testing itself, but the current behaviour is a bit inconsistent. Sorry no patch at the moment (I only came across this at home last night) and haven't had chance to fix it yet. R.