ELF binaries, a.out -- LONG

Patrick Head patrick at phead.net
Mon Jul 5 22:51:38 PDT 2004


On Mon, 2004-07-05 at 18:33, Ian Molton wrote:
> On Mon, 05 Jul 2004 21:07:03 -0400
> Steve <beforewisdom at yahoo.com> wrote:
> 
> > 
> > So a statically linked bianary wouldn't be an ELF?
> 
> sure it would. just one that doesnt need any libraries.

OK, here goes at a probably feeble attempt to explain Elves, I mean ELFs.

First off, a compiler, such as the gcc C compiler does nothing more
than create assembly language from the higher level language.  This
assembly is the native language of the underlying processor, such as
Intel Pentium (x86 and such), or SPARC.

Then the assembly is assembled into the actual binary machine code
that the processor can directly execute.

So far so good, but there is more to this.  In the days of old, this
was about all that was necessary.  But, wanting to provide for code
reuse and consistency, the programming world came up with code
libraries.  To reduce the amount of compiling, these libraries were
also "pre-compiled" into machine code, and once the application code
is compiled (and assembled) the whole mess is linked into one big
piece of code.

Still more ... the above scenario worked well when an entire program
was the only thing running on any given system.  Even with an underlying
operating system it was OK, such as CPM, or DOS, etc.

But multitasking OSes such as Unix have a problem.  All the directly
set addresses and locations of variables, tables, and code jump
points are fixed into the compiled binary file.  OK if we can always
predict where the program will load in memory, but on a multitasking
system we can't.  So, some way is needed to provide for memory
location fix ups at program load time.  Hence the need for methods
such as a.out, coff and ELF.  These systems provide for both
compile time fix ups needed to resolve locations across individual
modules, and for load time fix ups needed to relocate the entire
program into any given memory location.

Why a.out (or even coff from WAY back) and ELF??  Well, in a nutshell,
ELF is what provides for dynamic linking.  A term used to describe
the ability to provide shared libraries and "pluggable" software
components.  In other words, the final linking of all the pieces
can take place at run time, rather than compile time.  ELF is the
"everything but the kitchen sink" technology for linking pieces
of binary code into one cohesive piece of software.

My hope is that this message is a little bit understandable and
useful!

-- 
Patrick Head
patrick at phead.net





More information about the lfs-chat mailing list