Date: Wed, 30 Jul 1997 10:05:24 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jdp@polstra.com (John Polstra) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, current@FreeBSD.ORG Subject: Re: pccard and -current; a long way to go. :-( Message-ID: <199707301705.KAA05229@phaeton.artisoft.com> In-Reply-To: <199707300412.VAA07616@austin.polstra.com> from "John Polstra" at Jul 29, 97 09:12:58 pm
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.
^^^^
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707301705.KAA05229>