From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Jason Molenda Cc: gdb@sourceware.cygnus.com Subject: Re: gdb weekly snapshots Date: Wed, 12 Apr 2000 22:54:00 -0000 Message-id: <38F56065.4DC3944E@cygnus.com> References: <20000412112836.A3901@shell17.ba.best.com> <20000412113127.A7234@shell17.ba.best.com> X-SW-Source: 2000-04/msg00060.html Jason Molenda wrote: > > > Jonathan wrote: > > > > 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? > > Andrew wrote: > > > 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. > > Well yes, but why bother being pedantic? The filenames are all > eight characters longer than they need to be, when the longer name > provides no additional information. If you're going to download > a gdb snapshot, you're going to get dejagnu, deal with it. Why > burden the filenames with extraneous characters every day? The name did two things: it differentiated its self from the smaller gdb.tar.gz; the archive script would mapp ``co gdb dejagnu'' onto ``gdb+dejagnu''. Hmm, given that there is no longer a gdb.tar.bz2 I can probably be less pedantic. > > 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). > > Is this actually useful? If someone does > > cvs -d ... -z9 co gdb Suprisingly, when I stopped creating them, I was sent requests to put them back! Chopping them back to once a week was a compromize. I suspect it is quicker / easier to grab that then remember the correct CVS options :-) Andrew >From ac131313@cygnus.com Thu Apr 13 00:01:00 2000 From: Andrew Cagney To: Mark Kettenis Cc: gdb@sourceware.cygnus.com, msnyder@cygnus.com Subject: Re: Disabling lin-thread.c module Date: Thu, 13 Apr 2000 00:01:00 -0000 Message-id: <38F56FDE.A18A9165@cygnus.com> References: <200004101237.OAA29849@landau.wins.uva.nl> X-SW-Source: 2000-04/msg00061.html Content-length: 1815 Mark Kettenis wrote: > > 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. Using a cynical marketing approach :-) GDB 5.0 is all about getting new features and being able to boast about them. GDB 5.0 is also all about kick starting the public CVS repository and getting real community development. I suspect that people in mission critical situations will think twice about jumping on a new radical GDB 5.0 when: o they see an even/zero sub-version (always a bad sign :-) o they know a 5.1 is coming soon With respect to thread_db, my understanding is that it is no less functional (1) then the old GDB-4.18 while at the same time, definitely being better architecturally designed (true?). No matter how much testing effort is put in, it is always going to take a release before it becomes stable. Enable it now, and 5.1 should be ok. Enable it in 5.1 and 5.2 (a year from now?) is likely stable :-/ The decision is between the thread and Linux maintainers. The thread maintainer said ya, so linux maintainers? enjoy, Andrew :-) (1) Is that a polite way of saying ``no more buggy''? >From Stephane.Bihan@arccores.com Thu Apr 13 01:33:00 2000 From: Stephane.Bihan@arccores.com To: Andrew Cagney Cc: gdb@sourceware.cygnus.com Subject: Re: Makefile setting Date: Thu, 13 Apr 2000 01:33:00 -0000 Message-id: X-SW-Source: 2000-04/msg00062.html Content-length: 786 > > the ARC supported implementation of gdb we are trying to achieve is > > "extensible". > > The register description is minimal in the sense that only the basecase > > registers are described in REGISTER_NAMES. > > This description is updated (more registers are added) when we connect to the > > simulator. > > Hmm, I'd suggest investigating the multi-arch framework. It better > handles things like an architecture suddenly deciding it needs to be > changed. A target can also forced multi-arch to re-select its > architecture if needed. > > http://sourceware.cygnus.com/gdb/papers/multi-arch/ > > For the register extensions, are they known by arcExtMap or are they > obtained from the target? > They are extracted from the object file. Thanks anyway for the paper. Stephane.