Date: Mon, 08 Apr 1996 10:14:11 -0700 From: John Polstra <jdp@polstra.com> To: freebsd-hackers@freebsd.org Cc: witr@rwwa.com, imp@village.org, chuckr@Glue.umd.edu Subject: Re: GNU binutils port Message-ID: <199604081714.KAA23215@austin.polstra.com>
next in thread | raw e-mail | index | archive | help
Replying to several postings in this thread ...
Robert Withrow <witr@rwwa.com> wrote:
> I don't see a port for GCC or the binutils in the 2.1 release, and
> binutils don't seem to build out of the box on 2.1 (at least a
> plain old ./configure fails).
>
> Out of curiosity, why is that (both of thats that is... ;-)
I've made a couple of fairly serious attempts to get binutils-2.6
working for FreeBSD. I hate to sound discouraging, but it's a pretty
huge task.
First of all, there's little hope of bringing any of our current ld code
forward into binutils-2.6. Too much has changed in binutils. Also, I
don't think this would be the right approach, as it would simply bring
forward the same problems that we already have in our linker. E.g.:
undefined symbols referenced from shared libraries are not diagnosed;
symbols from static libs are preferred over those from shared libs,
regardless of command line order; and others.
In my first attempt to update binutils-2.6, I tried just massaging the
existing "i386-unknown-freebsd" target into working order. I actually
got that limping along, in the sense that it could link object files and
libraries together into programs that would execute under FreeBSD. But
there were still some small things wrong with the executables produced
by the linker. Worse, there was _no_ shared library support.
Worthless.
My next try was to take the existing SunOS/a.out target, and try to
adapt it to FreeBSD. This is a much more promising approach, because
the shared library support for SunOS is already present in binutils, and
our shared libraries are very similar to SunOS's. But of course, there
are some significant differences. The worst problem seems to be that
our dynamic symbols are a different shape than Sun's -- i.e., we've
added a "size" field. The existing binutils code assumes that dynamic
symbols look just like static symbols. And there doesn't seem to be a
way to modify just the dynamic symbol handling, short of copying the
entire SunOS support code (huge) and then changing a few details. I
don't like the idea of duplicating that much code (for maintenance
reasons), so again, I put it down and did something more fun. I still
think this is a viable approach, but I can only work on this stuff for
maybe a week at a time before it drives me temporarily insane.
Anybody who's ever worked on binutils can tell you that it's a
mind- boggling web of indirections. Nothing is what it appears to
be. Things that look like function calls turn out to be macros
that have been defined, undefined, and redefined, only to expand
to indirect function calls through a table that's also been defined,
undefined, and redefined. There is practically no documentation,
and almost all of it is out of date and wrong.
What I'm saying is: It's a _very_ frustrating and unrewarding thing to
work on. That's the real reason there's no FreeBSD port of
binutils-2.6.
Warner Losh <imp@village.org> wrote:
> There is some noise about ELF fixing all of this, but I'm not sure
> how much of that is GEE WIZZ stuff, and how much is production
> quality hardened code.
Right, that's my elfkit. It's not being "marketed" to non-ELF-developers,
that's true, but it seems to be quite solid. Here's one data point.
Recently, on a lark, I got into the XFree86 source directory, and typed
"elf-make World". (The kit includes a script "elf-make" that invokes
"make" in such a way as to use the ELF tools instead of the standard
a.out tools.) To my surprise, it succeeded at building all of the
X libraries and many of the programs. The only programs that wouldn't
build were those that needed libraries which I haven't ported to ELF.
(Mostly, the math library.) One program that did build OK was xclock.
On my -current system, I typed "./xclock" and it worked just fine. This
is with shared libraries, late binding, the whole nine yards. (Note:
Don't try this at home, yet. I was using newer stuff than the
currently-released version of elfkit. I'll release it soon. I've been
waiting on a couple of things from other people.)
The ELF compiler, assembler, and linker are much more solid than one
might think. The reason is that the Linux people have been testing them
and debugging them and _using_ them for a very long time now.
Chuck Robey <chuckr@Glue.umd.edu> wrote:
> Actually, that was John Polstra, and he did it for 2.1. According
> to the last I read, he was bringing it forward to -current ...
Right, Peter Wemm is working on getting the library changes integrated
into -current. I'll probably make one more 2.1-based release, just to
bring in many bug fixes that our friends over in the Linux camp
have come up with.
> but the Elfkit he made is in wcarchive's incoming.
I don't see it there, and in any case, I certainly didn't put it there.
The master site is:
ftp://ftp.polstra.com/pub/FreeBSD/elfkit/
Please read and understand the README.FIRST file before bothering to fetch
the kit. It's not for weenies (yet).
> It REQUIRES gcc and binutils.
Just to clear up any possible misunderstanding, it requires the
standard gcc-2.7.2 and binutils-2.6 sources from any GNU site. It
includes patches to those, to make them work properly for FreeBSD/ELF.
You don't have to do any porting yourself.
Back to Robert ...
> As you noticed, cross building is a legitimate reason for wanting
> both gcc and binutils to compile on FreeBSD.
As cross-development tools, they _will_ compile and work, out of the
box, on FreeBSD. They just don't work as native tools.
--
John Polstra jdp@polstra.com
John D. Polstra & Co., Inc. Seattle, Washington USA
"Self-knowledge is always bad news." -- John Barth
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604081714.KAA23215>