Re: Disabling lin-thread.c module

[Andrew Cagney <ac131313 at cygnus dot com>]

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''?