RFC: Obsoleting some symbol readers?

RFC: Obsoleting some symbol readers?

[Daniel Jacobowitz]

I was going through some cleanups to 'struct type' this evening and noticed
more abuse of copying types in dstread.c and hpread.c.  dstread.c is only
used by m68k-apollo-*, and I see that GCC 3.1 is deprecating this system;
perhaps we should do the same for the next cycle?

hpread, unfortunately, I don't think I can dismiss that easily :(  Guess
I'll have to fix it; it has similar problems to stabs with regard to
replacing incomplete types.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: Obsoleting some symbol readers?

[Daniel Jacobowitz]

On Sun, May 12, 2002 at 12:47:48AM -0400, Daniel Jacobowitz wrote:
> I was going through some cleanups to 'struct type' this evening and noticed
> more abuse of copying types in dstread.c and hpread.c.  dstread.c is only
> used by m68k-apollo-*, and I see that GCC 3.1 is deprecating this system;
> perhaps we should do the same for the next cycle?
> 
> hpread, unfortunately, I don't think I can dismiss that easily :(  Guess
> I'll have to fix it; it has similar problems to stabs with regard to
> replacing incomplete types.

Corollary to this:  dstread.c has not been compiled successfully since
at least 1995, when function_type was removed from struct type.  I
don't want to be the one to fix it :)

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: Obsoleting some symbol readers?

[Andrew Cagney]

> On Sun, May 12, 2002 at 12:47:48AM -0400, Daniel Jacobowitz wrote:
> 
>> I was going through some cleanups to 'struct type' this evening and noticed
>> more abuse of copying types in dstread.c and hpread.c.  dstread.c is only
>> used by m68k-apollo-*, and I see that GCC 3.1 is deprecating this system;
>> perhaps we should do the same for the next cycle?
>> 
>> hpread, unfortunately, I don't think I can dismiss that easily :(  Guess
>> I'll have to fix it; it has similar problems to stabs with regard to
>> replacing incomplete types.
> 
> 
> Corollary to this:  dstread.c has not been compiled successfully since
> at least 1995, when function_type was removed from struct type.  I
> don't want to be the one to fix it :)

os9kread.c has already been bug reported for obsolecence.

If nothing else bug report these.  Hmm, lets just obsolete the entire 
apollo line ...

Andrew

Re: RFC: Obsoleting some symbol readers?

[Daniel Jacobowitz]

On Sun, May 12, 2002 at 11:46:02PM -0400, Andrew Cagney wrote:
> >On Sun, May 12, 2002 at 12:47:48AM -0400, Daniel Jacobowitz wrote:
> >
> >>I was going through some cleanups to 'struct type' this evening and 
> >>noticed
> >>more abuse of copying types in dstread.c and hpread.c.  dstread.c is only
> >>used by m68k-apollo-*, and I see that GCC 3.1 is deprecating this system;
> >>perhaps we should do the same for the next cycle?
> >>
> >>hpread, unfortunately, I don't think I can dismiss that easily :(  Guess
> >>I'll have to fix it; it has similar problems to stabs with regard to
> >>replacing incomplete types.
> >
> >
> >Corollary to this:  dstread.c has not been compiled successfully since
> >at least 1995, when function_type was removed from struct type.  I
> >don't want to be the one to fix it :)
> 
> os9kread.c has already been bug reported for obsolecence.
> 
> If nothing else bug report these.  Hmm, lets just obsolete the entire 
> apollo line ...

Found this in the mailbox... since no one else commented, I'd like to
propose that we obsolete m68*-apollo*-bsd*.  I haven't seen even a
reference to it in years.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: Obsoleting some symbol readers?

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 105 bytes --]

No one said beep.  I guess it's time to formally propose it on 
gdb-announce@sources.redhat.com.

Andrew

[-- Attachment #2: mailbox-message://ac131313@movemail/fsf/gdb/misc#9466739 --]
[-- Type: message/rfc822, Size: 3856 bytes --]

From: Daniel Jacobowitz <drow@mvista.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sources.redhat.com
Subject: Re: RFC: Obsoleting some symbol readers?
Date: Sat, 20 Jul 2002 16:43:56 -0400
Message-ID: <20020720204356.GA2018@nevyn.them.org>

On Sun, May 12, 2002 at 11:46:02PM -0400, Andrew Cagney wrote:
> >On Sun, May 12, 2002 at 12:47:48AM -0400, Daniel Jacobowitz wrote:
> >
> >>I was going through some cleanups to 'struct type' this evening and 
> >>noticed
> >>more abuse of copying types in dstread.c and hpread.c.  dstread.c is only
> >>used by m68k-apollo-*, and I see that GCC 3.1 is deprecating this system;
> >>perhaps we should do the same for the next cycle?
> >>
> >>hpread, unfortunately, I don't think I can dismiss that easily :(  Guess
> >>I'll have to fix it; it has similar problems to stabs with regard to
> >>replacing incomplete types.
> >
> >
> >Corollary to this:  dstread.c has not been compiled successfully since
> >at least 1995, when function_type was removed from struct type.  I
> >don't want to be the one to fix it :)
> 
> os9kread.c has already been bug reported for obsolecence.
> 
> If nothing else bug report these.  Hmm, lets just obsolete the entire 
> apollo line ...

Found this in the mailbox... since no one else commented, I'd like to
propose that we obsolete m68*-apollo*-bsd*.  I haven't seen even a
reference to it in years.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer