--- Begin Message ---
- To: "'misc@openbsd.org'" <misc@openbsd.org>
- Subject: Re: Upgrade nightmare
- From: Marc Espie <espie@nerim.net>
- Date: Wed, 17 Apr 2002 18:24:30 +0200
- Message-id: <20020417182430.B14721@tetto.liafa.jussieu.fr>
- Mail-followup-to: "'misc@openbsd.org'" <misc@openbsd.org>
- Reply-to: espie@nerim.net
- In-reply-to: <20020417094753.GA13842@sigrid.schuldei.com>; from andreas@schuldei.org on Wed, Apr 17, 2002 at 11:47:53AM +0200
- References: <B3CF4D2DF451D411B27300D0B77E6A700DF156@vorlich.openkast.com> <20020417004647.A31635@tetto.liafa.jussieu.fr> <20020417094753.GA13842@sigrid.schuldei.com>
On Wed, Apr 17, 2002 at 11:47:53AM +0200, Andreas Schuldei wrote:
> * Marc Espie (espie@nerim.net) [020417 01:28]:
> > You are using the assembler from new-binutils, this is wrong.
>
> [...]
>
> > Except for us OpenBSD developers. Because you see, we went
> > through the same nightmare before, when we slowly took the
> > OS from 2.9 to 3.1... and most of the issues you are going
>
> Could you please give a short overview of what happend, where
> we are today and what the goal is? Are we moving to some enhanced
> ELF (OLF) and what can the new binutils do what the old could
> not? I noticed that there are still library versioning problems
> which are solved under linux. (just stumbled onto that...)
We don't have library versioning problems. We are using a simpler
scheme that just works. Tell me about what problems you think linux
solves, and I tell you how we don't need it :)
What the new binutils can do that we can't (yet):
- support for new i386 asm instruction. That could probably be patched in.
- elf sections, which means better support for debugging information
(though it's not perfect yet, because the tools need to coalesce info
more).
- dwarf unwind info, for C++ exception support.
- scripting. That can be used to handle ctors/dtors in better ways.
- some obscure bugs in symbol handling in shared libraries (yes, in ld).
- better memory usage for linking huge libraries (though the hack I've
just committed to ld alleviates that problem a great deal).
- in general, tighter cooperation with recent gcc releases. It's just
a question of testing gcc and fixing the various bits that have been
broken by the FSF recent releases, really.
- -zcomb-reloc, though that isn't perfect yet. In general, pre-linking
support is being worked on in very recent binutils. That's useful for
coalescing relocation info better in large shared code-based projects (see
the kde webpage for details)
We also have issues which are completely separate from binutils proper.
- some ld.so bugs, which probably kill mozilla.
- gdb has troubles with a.out pic information.
- thread support in general, and in particular in the C++ library and qt.
One large problem is that binutils may work, but the code is a piece of
junk. It is very convoluted, and it is very hard to find the piece of code
that you are looking for. The patterns used to make the code very flexible
are not at all apparent, and the various indirection mechanisms are very
poorly documented (most of the bfd functions are undocumented, the ld
scripting mechanism is poorly documented), and the functionality separation
is poor (you often find operating-system specific stuff in supposedly
arch-only files), plus there are lots of defines that contribute to
obfuscating the code (hard to find out what's compiled in ELF/ECOFF/AOUT
modes).
--- End Message ---