From owner-freebsd-hackers Mon Apr 8 10:14:34 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA10687 for hackers-outgoing; Mon, 8 Apr 1996 10:14:34 -0700 (PDT) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA10679 for ; Mon, 8 Apr 1996 10:14:31 -0700 (PDT) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.5/8.6.12) with ESMTP id KAA23215; Mon, 8 Apr 1996 10:14:12 -0700 (PDT) Message-Id: <199604081714.KAA23215@austin.polstra.com> To: freebsd-hackers@freebsd.org Cc: witr@rwwa.com, imp@village.org, chuckr@Glue.umd.edu Subject: Re: GNU binutils port Date: Mon, 08 Apr 1996 10:14:11 -0700 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Replying to several postings in this thread ... Robert Withrow 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 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 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