Date: Tue, 21 Jan 1997 12:49:42 -0800 From: John Polstra <jdp@polstra.com> To: David Greenman <dg@root.com> Cc: hackers@freebsd.org Subject: Re: Commerical applications (was: Development and validation Message-ID: <199701212049.MAA08515@austin.polstra.com> In-Reply-To: <199701201752.KAA15603@phaeton.artisoft.com> References: <199701201752.KAA15603@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> >3) ELF is desirable
>
> ELF is a bloated abomination that has numerous architectural problems and
> is good at making things slower.
David, I can't see why you're saying that. There are good reasons
why FreeBSD still uses a.out. But I don't think ELF is bloated,
or has numerous architectural problems, or makes things slower.
Regarding bloat, it is true that ELF is more complicated than a.out,
but it's not much more complicated. In my view, it has just about
the minimum additional complexity to support arbitrary sections
besides text, data, and BSS. Its symbol table is similar in spirit
to ours, as is its representation of relocations.
ELF executables and shared libraries generally use slightly less
space than a.out versions. That's because in a.out, the text,
data, and BSS sections are each padded to a muliple of the page
size (4096), whereas in ELF, only the address space as a whole is
padded. On average, each instance of this padding adds 2048 bytes.
So in execution, a.out wastes an average of 6K of padding, while
ELF has an average of 2K. In the executable file, BSS is not
represented explicitly. A.out pads both text and data, while ELF
doesn't pad at all in the file. The average difference there is
4K for a.out vs. 0 for ELF. For very small programs, the difference
is larger. As an example, here's the "hello world" program in
a.out:
austin$ cc -O hello.c -o hello.aout
austin$ strip hello.aout
austin$ ls -l hello.out
-rwxr-xr-x 1 jdp jdp 8192 Jan 21 12:34 hello.out
versus this for ELF:
austin$ elf-cc -O hello.c -o hello.elf
austin$ elf-strip hello.elf
austin$ ls -l hello.elf
-rwxr-xr-x 1 jdp jdp 2776 Jan 21 12:36 hello.elf
I don't know what architectural problems you're referring to. There
aren't any in the object format itself that seem severe to me.
I can't see that it's inherently slower to bring an ELF executable
into execution than an a.out executable. Each requires 3 mmap
operations, for text + data + BSS. For ELF, slightly fewer pages
have to be mmapped, because of the lack of padding that I mentioned
above. The runtime relocations and symbol lookups are comparable.
The lazy binding mechanism is very similar.
To me, the main obstacles in the way of switching to ELF are:
* FreeBSD doesn't need it nearly as badly as Linux needed it, because
our shared library support under a.out is incomparably better than
theirs was.
* It is hard to come up with a non-disruptive transition plan.
* There is gut-level opposition to it because it reeks of SVR4 and
Linux.
These obstacles have to be balanced against the big ELF advantage:
* The ELF language tools are actively maintained.
--
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?199701212049.MAA08515>