Subject: Re: Removal of old toolchain
To: None <firstname.lastname@example.org, email@example.com>
From: Jason R Thorpe <firstname.lastname@example.org>
Date: 09/15/2002 08:52:41
On Sun, Sep 15, 2002 at 06:43:55PM +0900, ITOH Yasufumi wrote:
> The a.out world is still working. Will you please keep it?
Sure, the a.out world "still works", but the NetBSD project as a whole
doesn't really have any interest in maintaining it. Having both toolchains
in the source tree contributes greatly to the size of the source tree; we
need to trim the fat in this regard.
> I think keeping a.out would contribute to quality of our code base.
> For example, the traditional a.out toolchain places static data
> more densely than the ELF toolchain.
> I'm currently using a.out on i386, and have found some off-by-one
> errors which does not occur on ELF toolchain.
Hm. What specific errors have you found?
BTW, you can get ELF to arrange data more-or-less like a.out, as well. All
you need to do is write a linker script for it.
> So, will you please
> 1. port the a.out handling to the new toolchain, or
> 2. keep (at least) the old gas / ld for now?
(1) isn't really feasible. That is, an effort was made to do this (by
kristerw) some time ago, but the return on time investment is too small.
You are certainly welcome to do this work (and *please* file a copyright
assignment with FSF if you do this, because the Project is trying very
hard to get to the point where we can use stock GNU toolchain pieces).
However, keep in mind that we'll be importing updated binutils soon'ish,
and when it comes to merging the code base, I'm likely to clobber the
larval a.out pic support in there, rather than try to merge it. Your best
bet is to make the changes to support a.out pic in binutils-current and
feed the changes directly back to the master binutils sources.
(2) is no problem; they are in the 1.6 source tree, and will always be
available in the CVS Attic. However, the revisions will be marked dead
on the HEAD, in order to shrink the size of the checked-out repository.
This is consistent with the policy expressed in the original toolchain
> I prefer 1., of course. :)
I understand your dilemma. However, we have limited resources (people's
time) for maintaining our toolchain, and we need to take steps to make
the process easier. We made a big leap forward with the NEW_TOOLCHAIN
stuff, and we are very close to being able to use stock GCC and Binutils
right out of the box (with some minimal integration work when updating to
-- Jason R. Thorpe <email@example.com>