Date: Tue, 29 Jul 1997 21:12:58 -0700 From: John Polstra <jdp@polstra.com> To: Terry Lambert <terry@lambert.org> Cc: msmith@atrad.adelaide.edu.au, current@FreeBSD.ORG Subject: Re: pccard and -current; a long way to go. :-( Message-ID: <199707300412.VAA07616@austin.polstra.com> In-Reply-To: Your message of "Tue, 29 Jul 1997 17:33:08 PDT." <199707300033.RAA03703@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
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?
* 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.
* 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.) The underscore problem affects lots of areas:
- assembly language code that references C globals
- all programs that call nlist()
- all programs that call dlopen()
There are versions of nlist floating around that address this
problem, and dlopen() could be made to do the right thing most of
the time too.
* Work out a build structure that will allow an a.out->ELF make
world.
* 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.
> 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 */
#else
#define KERNCALL LCALL(7,0) /* The old way */
#endif
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.
--
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?199707300412.VAA07616>