[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: Cleanups for the m68k backend
From:       Marc Espie <espie () quatramaran ! ens ! fr>
Date:       2003-07-08 22:37:09
[Download RAW message or body]

In article <200307081130.07956.bernie@develer.com> you write:
> I still don't understand why the OpenBSD people didn't upgrade their
>assembler the same way the NetBSD people did. Their system
>requirements are pretty much the same.

You're completely wrong. 

Our build model is very much different.

These days, NetBSD builds most of its arches using cross-compilation.
OpenBSD development insists on native compilation. For starters, it
has found bugs, and helps keep old targets alive by making sure they
can at least run through a make build.  
So, we don't have a complete cross-compilation framework, and it's not
seen as a priority.

We also don't like to have lots of knobs through the system, and transition
phases, like having two distinct compilers on different architectures,
is frowned upon.

We also have toolchain speed issues. Switching to a brand new toolchain
(and a slow one) is a hard decision, if it means having build time jump
from 3 days to one week on a m68k machine.

Also, we have some different changes in our compiler. We have integrated
propolice since OpenBSD 3.3. We don't use binutils ld.so, we can't, because
it doesn't have a free enough license for our goals.

And our runtime linker includes support for W^X: on elf platforms, our 
dynamic libraries and executable have more sections, because we separate
relocatable code from PLT tables and reloc information, and our ld.so
tries to ensure no code section ever is writable and executable at the
same time.

Thus, focus on distinct issues, and other development issues, mean we don't
track some areas of NetBSD development very closely...

if you could just drop in a new binutils, a new gcc, a new gdb, and have
a nice up-and-running system that's faster than the old one, we would do it.
Unfortunately, the reality is different: there are hard to track bugs in
the toolchain, sometimes the produced binaries are too large (a 1% increase
in kernel size can kill us), often the toolchain gets much slower, and so
such changes need very careful testing.

If you haven't already, shake out the misconception that OpenBSD is just
NetBSD plus a few security changes. That hasn't been true for the last
five years or so. NetBSD and OpenBSD are distinct systems that share a
common ancestor and still do some cross-fertilization.

Have a real look in those two projects tech* mailing-lists, you'll see how
long it took NetBSD platforms to switch to elf, you'll realize that this
change has been controversial on some platforms (vax, for instance), and
you'll see that similar issues do exist on OpenBSD.
[prev in list] [next in list] [prev in thread] [next in thread]