ELF binaries, a.out -- LONG

Patrick Head patrick at phead.net
Tue Jul 6 01:41:26 PDT 2004


On Tue, 2004-07-06 at 01:03, Ian Molton wrote:
> On Mon, 05 Jul 2004 22:51:38 -0700
> Patrick Head <patrick at phead.net> wrote:
> 
> > 
> > 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.
> 
> Not strictly true. OSes like linux use the MMU available in typical
> modern system (yes I know about uClinux). This allows them to actuially
> give every application an identical memory space. the applications
> usually are linked to run at the lowest usable address in this range
> (0x8000 for ARM I think) and the stack starts at the other end.
> 
> What *isnt* predictable, is where the shared libraries appear in the
> memory map, and this is where the dynamic  linker and ELF come in...

Thanks Ian for the clarification on this point.  I am sure that my
description could be picked apart on many levels.  I am an
instructor by trade, and have a habit of omitting some finer details
when giving an overview, but once again, this is a very important
point!

-- 
Patrick Head
patrick at phead.net





More information about the lfs-chat mailing list