From owner-freebsd-current Wed Jul 30 10:07:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA16074 for current-outgoing; Wed, 30 Jul 1997 10:07:56 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA16063 for ; Wed, 30 Jul 1997 10:07:52 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA05229; Wed, 30 Jul 1997 10:05:24 -0700 From: Terry Lambert Message-Id: <199707301705.KAA05229@phaeton.artisoft.com> Subject: Re: pccard and -current; a long way to go. :-( To: jdp@polstra.com (John Polstra) Date: Wed, 30 Jul 1997 10:05:24 -0700 (MST) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, current@FreeBSD.ORG In-Reply-To: <199707300412.VAA07616@austin.polstra.com> from "John Polstra" at Jul 29, 97 09:12:58 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I think you need to document what needs to be done here. I would > > be happy to run an ELF kernel in my now (mostly) non-ELF environment. ^^^^ This "non-" shouldn't be here... sorry! > Well, there are a zillion things that need to be done. Just off the > top of my head: > > * Solve the booting problem. My hacked-up bootloader was within > about 6 bytes of the maximum size -- way too big to commit. GRUB? > An a.out wrapper for the ELF kernel? Frankly, I'd be happy to live with your hacked-up boot loader. I expect the whole boot code thing to change significantly, eventually. It nearly hit critical mass in the last "bootfs" discussion; it will take one or two more discussions before someone who is an acceptable code source for commit actually does the code. > * Design a directory structure for the toolchain components so that > it's reasonable to have both a.out and ELF tools installed at the > same time. I'm not terrifically concerned with this, either. If this is an issue, then the correct respone is to support BSD a.out more fully in binutils, especially the linker. > * Work out the various problems that stem from the fact that a.out > prepends a leading underscore to global symbol names while ELF does > not. (The usual reply to this is "let's just make our ELF tools > prepend the underscore too," although I bet you know better than > that. You're not allowed to do it because the ELF spec says you > can't. If we want ELF, then let's have ELF and not elf.out or > a.elf.) Don't be so sure that I am not an "underscore advocate". There's plenty of code that distinguishes the assembly from the C symbol name space using underscores... the non-underscore functions are a means of providing duplicate symbol hiding. In many cases, the removal of the C symbol underscore is BAD(tm), in that it causes a collision with an assembly function of the same name. I could see this being a *big* problem for an in-kernel math emulator (one example). > * Work out a build structure that will allow an a.out->ELF make > world. "Just Do It" (tm). Specifically, a build world works for the a.out -> a.out update; there's no reason that, if the tool defaults change and the kernel supports ELF image activation, that the same won't "just work" for a.out -> ELF. The *only* possible stumbling block I see is the existance of tandem shared libraries perhaps taking too much space. A binutils that knew about a.out *should* fix this; the biggie is a replacement ld.so for a.out that can link ELF shared libraries instead (or in addition to) a.out shared libraries. > * Consider the feasibility of mixed linking combining both ELF and > a.out object modules and libraries. Likewise for dynamic linking. > Some people have a.out libraries and executables which they paid > money for. They don't want to throw them away. Again, the > underscore problem is an obstacle here. Binutils. And the libraries with colliding C/asm namespaces are the main argument for doing the underscore in the conversion. Generally, I'd say add a flag bit, and let the linker know about it, and have binutils set the falg on conversion. This is about as close as you could get to fully transparent operation. > > Did you use the "fast call" conventions on the ELF kernel system > > calls? This would imply a libc rebuild, right? > > Are you talking about this in "src/lib/libc/i386/SYS.h"? > > #ifdef __ELF__ > #define KERNCALL int $0x80 /* Faster */ [ ... ] yes. > And by the way, can somebody explain why system calls care about the > object file format of the application making the calls? It's not > obvious to me. Apparently, the int gate is only there if the ELF stuff is there, and it's faster. The reason for the difference is lame backward compatability support for the new feature (IMO). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.