Obsolete systems for GDB 5.1?

Obsolete systems for GDB 5.1?

[Andrew Cagney]

I'd like to table the following as candidates for removal from GDB. 
They would be marked as obsolete in GDB 5.1.


The following systems were identified because they continue to use the
*xdep.c* file.

Rather than fix these platforms, I'd like to remove them.  Eliminating
*xdep.c from GDB should greatly simplify things like the move to
automake (and more immediatly the long outstanding need to fix
gdb/gdbserv's configury).

	m68030-sony-*)		gdb_host=news1000 ;;
	m68*-isi-*)		gdb_host=isi ;;
	m68*-sony-*)		gdb_host=news ;;
	a29k-*-*)		gdb_host=ultra3 ;;
	ns32k-umax-*)		gdb_host=umax ;;
	mpw*-*-*)		see mpw-config.in


The following systems were identified because they they do not have a
maintainer and are known to not build:

	i[3456]86-*-sunos*)	gdb_host=sun386 ;;  (This is *NOT* solaris-2)
	ns32k-umax-*)		gdb_host=umax ;;
		Uses deleted function safe_strsignal().


The following systems were identified because their target does not have
a maintainer *AND* I was not able to build them (FreeBSD host).  The
file gdb/MAINTAINERS will contain up-to-date status on this and other
targets.

	i960
	mcore
	mn10200
	ns32k
		ns32k-*-mach3*)		gdb_host=ns32km3 ;;
		ns32k-*-netbsd*)	gdb_host=nbsd ;;
		ns32k-umax-*)		gdb_host=umax ;;
		ns32k-utek-sysv*)	gdb_host=merlin ;;
	tic80
	v850
	w65
	z8k

Comments.  Suggestions and rejections.

	Andrew

Re: Obsolete systems for GDB 5.1?

[Christopher Faylor]

FWIW, I think that the removal of all of these makes sense.

cgf

On Thu, Jan 18, 2001 at 03:22:07PM +1100, Andrew Cagney wrote:
>I'd like to table the following as candidates for removal from GDB. 
>They would be marked as obsolete in GDB 5.1.
>
>
>The following systems were identified because they continue to use the
>*xdep.c* file.
>
>Rather than fix these platforms, I'd like to remove them.  Eliminating
>*xdep.c from GDB should greatly simplify things like the move to
>automake (and more immediatly the long outstanding need to fix
>gdb/gdbserv's configury).
>
>	m68030-sony-*)		gdb_host=news1000 ;;
>	m68*-isi-*)		gdb_host=isi ;;
>	m68*-sony-*)		gdb_host=news ;;
>	a29k-*-*)		gdb_host=ultra3 ;;
>	ns32k-umax-*)		gdb_host=umax ;;
>	mpw*-*-*)		see mpw-config.in
>
>
>The following systems were identified because they they do not have a
>maintainer and are known to not build:
>
>	i[3456]86-*-sunos*)	gdb_host=sun386 ;;  (This is *NOT* solaris-2)
>	ns32k-umax-*)		gdb_host=umax ;;
>		Uses deleted function safe_strsignal().
>
>
>The following systems were identified because their target does not have
>a maintainer *AND* I was not able to build them (FreeBSD host).  The
>file gdb/MAINTAINERS will contain up-to-date status on this and other
>targets.
>
>	i960
>	mcore
>	mn10200
>	ns32k
>		ns32k-*-mach3*)		gdb_host=ns32km3 ;;
>		ns32k-*-netbsd*)	gdb_host=nbsd ;;
>		ns32k-umax-*)		gdb_host=umax ;;
>		ns32k-utek-sysv*)	gdb_host=merlin ;;
>	tic80
>	v850
>	w65
>	z8k
>
>Comments.  Suggestions and rejections.

Re: Obsolete systems for GDB 5.1?

[J.T. Conklin]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> I'd like to table the following as candidates for removal from
Andrew> GDB.  They would be marked as obsolete in GDB 5.1.  The
Andrew> following systems were identified because their target does
Andrew> not have a maintainer *AND* I was not able to build them
Andrew> (FreeBSD host).  The file gdb/MAINTAINERS will contain
Andrew> up-to-date status on this and other targets.
Andrew>
Andrew> 	ns32k
Andrew> 		ns32k-*-mach3*)		gdb_host=ns32km3 ;;
Andrew> 		ns32k-*-netbsd*)	gdb_host=nbsd ;;
Andrew> 		ns32k-umax-*)		gdb_host=umax ;;
Andrew> 		ns32k-utek-sysv*)	gdb_host=merlin ;;
Andrew>
Andrew> Comments.  Suggestions and rejections.

I'll be fixing the ns32k-*-netbsd* before 5.1.  

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: Obsolete systems for GDB 5.1?

[Jonathan Larmour]

In article < 3A666F6F.90372D25@cygnus.com > you write:
>I'd like to table the following as candidates for removal from GDB. 
>They would be marked as obsolete in GDB 5.1.
[snip]
>	v850

It may not build right now, but we support this within Red Hat. Just
because there is no individual capable of being the maintainer
doesn't mean that no-one will be fixing it: the entity known as
Red Hat as a whole will.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

Re: Obsolete systems for GDB 5.1?

[J.T. Conklin]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> 	ns32k
Andrew> 		ns32k-*-mach3*)		gdb_host=ns32km3 ;;
Andrew> 		ns32k-*-netbsd*)	gdb_host=nbsd ;;
Andrew> 		ns32k-umax-*)		gdb_host=umax ;;
Andrew> 		ns32k-utek-sysv*)	gdb_host=merlin ;;
Andrew>
Andrew> Comments.  Suggestions and rejections.

It seems that much of the ns32k build lossage was caused by a change
made to tm-umax.h between the 19990504 and 19990525 snapshots (I can
not narrow it down further, this was before the GDB repository on
sourceware was made the master repository, perhaps someone at cygnus
can track it down) where the FRAME_FIND_SAVED_REGS macro was removed.
There was no ChangeLog entry cooresponding to this change.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: Obsolete systems for GDB 5.1?

[Andrew Cagney]

What happens next? (so no one goes into a mad panic :-)

What I'm planning on doing is roughly as follows:

	o	let this e-mail bounce
		around for a few weeks

	o	once it has settled I'll re-post

	o	I'll then post that to gdb-announce
		(I'm tempted to post one announcement
		per message, with the deleted system
		in the subject line.  That way people
		can't deny that they didn't see it :-)

	o	I'll then enact it

enjoy,
	Andrew

Re: Obsolete systems for GDB 5.1?

[Mark Kettenis]

Andrew Cagney <ac131313@cygnus.com> writes:

> I'd like to table the following as candidates for removal from GDB. 
> They would be marked as obsolete in GDB 5.1.
> 
> The following systems were identified because they they do not have a
> maintainer and are known to not build:
> 
> 	i[3456]86-*-sunos*)	gdb_host=sun386 ;;  (This is *NOT* solaris-2)

Yes, please!

I'd also like to propose the following:

i[3456]86-*-aix*)	gdb_target=i386aix ;;
i[3456]86-*-osf1mk*)	gdb_target=i386mk ;;

I seriously doubt that there are still PS/2 AIX boxen alive, and I
believe the OSF 1 doesn't even compile.

Mark