This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Removal of VAX/VMS support
- From: Ian Lance Taylor <ian at airs dot com>
- To: Jim Blandy <jimb at redhat dot com>
- Cc: DJ Delorie <dj at delorie dot com>, binutils at sources dot redhat dot com
- Date: 31 Jul 2003 23:25:38 -0700
- Subject: Re: Removal of VAX/VMS support
- References: <Pine.LNX.4.30.0307311028210.19470-100000@ds9.reckziegel.com><3F291ABA.8030803@redhat.com><200307311344.h6VDiwIE017363@envy.delorie.com><3F292F8F.10003@redhat.com><200307311527.h6VFRohe001552@envy.delorie.com><vt2y8yeozc1.fsf@zenia.home>
Jim Blandy <jimb@redhat.com> writes:
> For GDB, marking ports as obsolete and eventually deleting them has
> the advantage that clients of old interfaces to core functionality
> gradually disappear. Once they're all gone, you can delete whatever
> cruft in the core was supporting the old interfaces, which often frees
> you up to do better things with the core. I can't wait until the
> clients of the old stack unwinding interfaces are gone from GDB ---
> that stuff is hard to reason about, and easy to use wrong. But
> because Andrew goes around threatening to delete ports if they don't
> get reworked to use the new interfaces (that's not quite an accurate
> description of the tactic, but it's something like that), they will
> eventually no longer be present to confuse people.
I think it's worth pointing out that gdb is quite a bit more
complicated than the binutils. The binutils are all conceptually
quite simple. gdb is tougher because it has to look at the code in an
unnatural way--pulling it backward from executable to source. The
binutils all go in the natural direction, from source to executable
(except for objdump --disassemble or --debugging, I suppose).
The conceptual complexities people encounter with the binutils are
mainly a matter of understanding the somewhat inappropriate design and
the very confusing implementation, not the actual task which the
program is supposed to do.
Ian