Re: gdb weekly snapshots

[Andrew Cagney <ac131313@cygnus.com>]

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 <ac131313@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
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 <ac131313@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Makefile setting
Date: Thu, 13 Apr 2000 01:33:00 -0000
Message-id: <OFC6C77343.9E18E252-ON802568C0.002E5E4F@risccores.com>
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.