Removal of VAX/VMS support

[Ian Lance Taylor]

Andrew Cagney <ac131313@redhat.com> writes:

> I still think it is closer to the truth than we'd like to admit.  How
> come >10 years after bfd's introduction, I still find:
> 
> 	gas/config/vms-conf.h:48:#undef BFD_ASSEMBLER

Code with BFD_ASSEMBLER undefined actually still does use BFD, except
for a few surviving a.out targets--probably just m68k and vax,
actually.  The name is poorly chosen.

I agree that vms-conf.h has most likely bitrotted.  The VMS target
support is being maintained.  The VMS host support has not been
touched since 1998.

> In terms of age, BINUTILS and GDB also appear to be the same vintage,
> GDB is '86ish and GAS has (C) notices that go back to that same year.

It's somewhat deceptive.  gas was essentially completely rewritten
when it was converted to use BFD in the 1991-92 timeframe, when the
version numbers changed to 2.0.  Some of the code can still be
recognized in 1.x, but not much.

> In terms of performance, just like GCC and GDB, there it is an
> expectation that BINUTILS will keep with the competition.  If it
> doesn't then it is getting slower.

I don't know whether people have that expectation about the binutils.
They shouldn't.  There is plenty of room for improvement.  In
particular, the BFD linker has never maintained parity with the
Solaris linker.

> I should also note that I don't want to take anything away from the
> BINUTILS / BFD architecture.  The fact that things have lasted this
> long tells us that the underlying design is very sound.  It is just
> that I'd like to see people free to push the design harder.

Actually, I disagree with you on this point.  I don't think the
underlying design of BFD is particularly sound.  It is, however, very
flexible, and thus can be contorted to support whatever is needed.
When I rewrote the linker several years ago to make it much faster,
the key element of the design (which was done by SAC), was to break
the underlying design of BFD.

I think it was in 1993 that I first suggested that BFD needed to be
scrapped, and redesigned and rewritten from scratch.  Needless to say,
Cygnus never cared to pay for that effort.


All of this is irrelevant to the main question of whether BFD should
maintain support for obsolete targets.  My experience with BFD is that
maintaining that support is very cheap.  This is a result of BFD's
design, in which new features are typically added on without touching
existing code.  The BFD_JUMP_TABLE macros generally cause old targets
to be automatically updated without requiring anybody to actually
touch the files.

But if people want to go to the effort of discarding old files, that
is fine with me.

Ian