headers
Jason R Thorpe | 14 Sep 2002 18:40

Removal of old toolchain

Folks...

I am planning on removing the old toolchain (i.e. the stuff that gets
built when USE_NEW_TOOLCHAIN is not set) from the tree.  This should
shrink the side of the source tree considerably (no more "2 copies
of GCC, 2 copies of binutils", etc.)

This is going to leave pc532 out in the cold.  However, there has been
some movement wrt. gcc 3.x on ns32k, and it will be possible to build
a static ns32k universe using gcc 3.3/binutils 2.13 + the USE_NEW_TOOLCHAIN
framework.

The ns32k effort should now be directed at defining an ELF ABI for ns32k,
implementing it in bintuils-current (should be able to leverage the VAX
work here), adding ELF support for ns32k to gcc-current, and then adding
PIC support to that.

In any case, as the old toolchain removal was planned for after the 1.6
release, its removal will begin on Monday.  The old toolchain sources will
remain in the Attic, so it will still be possible to browse their revision
history (and even check out the copy tagged for 1.6).

--

-- 
        -- Jason R. Thorpe <thorpej <at> wasabisystems.com>
Permalink | Reply | 0 comments |
headers
ITOH Yasufumi | 15 Sep 2002 11:43
Picon

Re: Removal of old toolchain

In article <20020914094043.S2597 <at> dr-evil.shagadelic.org>
thorpej <at> wasabisystems.com writes:

> I am planning on removing the old toolchain (i.e. the stuff that gets
> built when USE_NEW_TOOLCHAIN is not set) from the tree.  This should
> shrink the side of the source tree considerably (no more "2 copies
> of GCC, 2 copies of binutils", etc.)

The a.out world is still working.  Will you please keep it?

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.

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?

I prefer 1., of course. :)

Currently, the new toolchain doesn't handle a.out correctly.
 - missing PIC/shared object support on ld,
 - .weak support is broken (C++ programs dump core).

I tried to make the new toolchain work for a.out
and I succeeded (probably) to make gas working for PIC,
but I failed to fix the above problems....
--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jaromir Dolecek | 15 Sep 2002 12:52
Picon

Re: Removal of old toolchain

ITOH Yasufumi wrote:
> I tried to make the new toolchain work for a.out
> and I succeeded (probably) to make gas working for PIC,
> but I failed to fix the above problems....

The right thing forward is to fix NEW_TOOLCHAIN for your needs,
not to keep using the old toolchain forever. You can always
get the old toolchain off cvs, so there isn't any reason to not remove
the old toolchain.

However, I think your time would be better spent on other things,
rather than maintaining a.out toolchain for NetBSD. Note that
only ELF toolchain is supported option, a.out has been kept for
transition reasons only.

Jaromir
--

-- 
Jaromir Dolecek <jdolecek <at> NetBSD.org>            http://www.NetBSD.org/
-=- We should be mindful of the potential goal, but as the tantric    -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow.   Do not let this distract you.''     -=-
Permalink | Reply | 0 comments |
headers
Jason R Thorpe | 15 Sep 2002 17:52

Re: Removal of old toolchain

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?

*sigh*

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
ITOH Yasufumi | 16 Sep 2002 01:50
Picon

Re: Removal of old toolchain

In article <20020915085241.F2597 <at> dr-evil.shagadelic.org>
thorpej <at> wasabisystems.com writes:

>  > 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?

Please take a look at
	pkgsrc/audio/cdparanoia/patches/patch-ae (search for "dispcache")
	pkgsrc/sysutils/xbatt/patches/patch-ab   (first hunk)

I found and fixed them since I tested them on a.out toolchain.

If a program is only tested on ELF toolchain, the quality of code
is like this.

ELF has other too unique features (ex. C symbols and assembler symbols
are same, dynamic linker automatically loads dependent libraries),
which make it easy to write non-portable programs.

> 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.

I don't think that the layout of initialized data can be re-arranged
in linker stage.

> (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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason R Thorpe | 16 Sep 2002 02:01

Re: Removal of old toolchain

On Mon, Sep 16, 2002 at 08:50:35AM +0900, ITOH Yasufumi wrote:

 > ~300KB is not acceptable in the HEAD?
 > 
 > 287     src/gnu/usr.bin/ld
 > 
 > Mmm, gas / gas.new may not be acceptable....
 > 
 > gas:
 > 2682    src/gnu/usr.bin/gas

I am keeping the old old ld and the old old gas around for reference
purposes, for now.  What I am deleting is the egcs compiler and the
2.9-vintage binutils.

 > gas.new:
 > 6495    src/gnu/dist/bfd
 > 4735    src/gnu/dist/gas
 > 1212    src/gnu/dist/include
 > 1795    src/gnu/dist/opcodes
 > 2185    src/gnu/lib/libbfd
 > 167     src/gnu/usr.bin/gas.new
 > 16589   total

...and combine that with egcs...  I reclaimed a whole bunch of disk space
when I removed these :-)

--

-- 
        -- Jason R. Thorpe <thorpej <at> wasabisystems.com>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason R Thorpe | 16 Sep 2002 02:06

Re: Removal of old toolchain

On Mon, Sep 16, 2002 at 08:50:35AM +0900, ITOH Yasufumi wrote:

 > Please take a look at
 > 	pkgsrc/audio/cdparanoia/patches/patch-ae (search for "dispcache")
 > 	pkgsrc/sysutils/xbatt/patches/patch-ab   (first hunk)
 > 
 > I found and fixed them since I tested them on a.out toolchain.
 > 
 > If a program is only tested on ELF toolchain, the quality of code
 > is like this.

Eh.  While I do believe you that the different object format exposed these
bugs, I'm not sure a blanket statement like "quality of code is like this"
is really fair nor accurate.  It's like saying we should all use Alphas
instead of x86 systems so that finding unaligned access bugs is easier.

 > ELF has other too unique features (ex. C symbols and assembler symbols
 > are same, dynamic linker automatically loads dependent libraries),
 > which make it easy to write non-portable programs.

Err... There are lots of other things that make it easy to write non-portable
programs, too.  Should we remove the err(3)/warn(3) family of functions from
our C library?

 > > 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.
 > 
 > I don't think that the layout of initialized data can be re-arranged
 > in linker stage.
(Continue reading)

Permalink | Reply | 0 comments |
headers
matthew green | 16 Sep 2002 03:48
Picon
Favicon

re: Removal of old toolchain


yay!
Permalink | Reply | 0 comments |
headers
ITOH Yasufumi | 16 Sep 2002 04:16
Picon

Re: Removal of old toolchain

This discussion is probably useless.  :)

In article <20020915170644.H505 <at> dr-evil.shagadelic.org>
thorpej <at> wasabisystems.com writes:

> On Mon, Sep 16, 2002 at 08:50:35AM +0900, ITOH Yasufumi wrote:
>  > If a program is only tested on ELF toolchain, the quality of code
>  > is like this.
> 
> Eh.  While I do believe you that the different object format exposed these
> bugs, I'm not sure a blanket statement like "quality of code is like this"
> is really fair nor accurate.  It's like saying we should all use Alphas
> instead of x86 systems so that finding unaligned access bugs is easier.

Yeah, but I'm under impression that
  ``This program is developed in a.out, and just works for other formats''
is more probable than that
  ``This program is developed in ELF, and just works for other formats''
where the program is supposed to be a portable C program.

I said this as quality.

>  > ELF has other too unique features (ex. C symbols and assembler symbols
>  > are same, dynamic linker automatically loads dependent libraries),
>  > which make it easy to write non-portable programs.
> 
> Err... There are lots of other things that make it easy to write non-portable
> programs, too.  Should we remove the err(3)/warn(3) family of functions from
> our C library?
(Continue reading)

Permalink | Reply | 0 comments |
headers
ITOH Yasufumi | 16 Sep 2002 04:17
Picon

Re: Removal of old toolchain

In article <20020915170119.G505 <at> dr-evil.shagadelic.org>
thorpej <at> wasabisystems.com writes:

> I am keeping the old old ld and the old old gas around for reference
> purposes, for now.  What I am deleting is the egcs compiler and the
> 2.9-vintage binutils.

>  > gas.new:

> ...and combine that with egcs...  I reclaimed a whole bunch of disk space
> when I removed these :-)

Ah, that is little problem to me.  Please go ahead.

I'm using gcc 2.95.3 (I feel egcs was a little robuster, though.
Possibly the gcc developers use ELF :) oldest gas or gas.new,
and the oldest ld.
On i386, gas 2.11.2 is almost working modulo .weak.
--

-- 
ITOH Yasufumi
Permalink | Reply | 0 comments |

Gmane