Removal of VAX/VMS support

[Andrew Cagney]

>> GDB partially addressed the problem by following a process of:
>> introducing a new interface; deprecating the old interface; provide a
>> legacy implementation that reverts back to the old / deprecated
>> mechanisms; eventually deleting the deprecated code.  It has made it
>> possible to implement core changes without also rewrite all
>> targets. Target maintainers can then, later, upgrade their target - cf
>> frame rewrites currently occuring in GDB.
> 
> 
> BFD follows a much simpler procedure.  New interfaces are introduced,
> and old interfaces remain.  No deprecation, legacy implementation, or
> deletion is required.

GDB was very much like that.  The emphasis was on quickly and cheaply, 
and with out breaking anything, adding lots of new targets.  This had 
the unintend consequence of encouraging contributors to minimizing core 
changes, they would instead take the easier path of adding increasingly 
silly architecture / target macros.  For instance:

- INIT_FRAME_PC vs INIT_FRAME_PC_FIRST
- FRAME_ARGS_ADDRESS vs FRAME_ARGS_ADDRESS_CORRECT
- CALL_DUMMY_STACK_ADJUST, STACK_ALIGN and NO_EXTRA_ALIGNMENT_NEEDED 
(all of which failed to correctly align the inferior stack).

Eventually a crunch occured and the emphasis started shifting towards 
the need to fix the underlying problems.  I think two factors triggered 
this: multi-arch(1), which made the problem clear; and the lack of new 
architectures, a consequence of the hi-tech crash.

But whats all this got to do with BINUTILS?  GDB needs to improve the 
performance (cpu and memory) of its symbol table and that will, in part, 
involve modifications to the GDB-BFD interface.  GDB has a very big 
interest in seeing BFD/BINUTILS evolve in ways that benefit GDB :-)

Andrew

(1) I should mention that Cygnus did fund much of this