Re: Likely obsolete pieces of GDB

[Daniel Jacobowitz <drow at false dot org>]

Thanks to everyone who replied!  I'll collect all the feedback and
revise the list - either next week or after I get back from my
holiday vacation.

On Sun, Dec 17, 2006 at 01:20:29PM +0100, Mark Kettenis wrote:
> Yes, it is time for these to go.  The main reason they're still there is
> because our current procedure for obsoleting targets is too complicated
> and too ugly.  I really can't get myself to put OBSOLETE on every line of
> the affected source files.  Can we change the policy to something like
> what the GCC people do?  They put a stanza in config.gcc that lists the
> obsolete configs and bails out on those configs unless the user
> specifies --enable-obsolete.  Then the config gets removed completely
> after the next release.
> 
> That said, I don't really have a problem with zapping these now.

I am happy to change the mechanism; I don't like // OBSOLETE either. 
We can't even use the current mechanism for some of these files:
anything not directly corresponding to a target.

To be honest, I'd been thinking about waiting for everyone to agree on
which things to remove, sending a message to gdb-announce, and then
just doing it.  If there were any justifiable complaints at the time of
the next release we could recover targets from CVS history.  I'm sure
not everyone is comfortable with that sudden of an approach, so
using configure for targets for one release is fine with me too.

> >  mdebugread.c
> >  mdebugread.h
> >
> >  	If there's any platform left that still produces this format
> >  	of symbolic debug information, I don't know what it is.
> 
> I think these are still necessary for Alpha (alpha-mdebug-tdep.c).

This is the only file I've seen any objections to that I really wanted
to get rid of, but it looks like you're right.  Do you know which Alpha
configurations are likely to use it, so that we can know when we don't
need it any more?  Maybe it's all the ECOFF ones.

-- 
Daniel Jacobowitz
CodeSourcery