William Case wrote:
>
> That solves that part. Will look at the goobly-gook of elf again. (It's
> not really goobly-gook. It is more like Greek to me.)
Bill - your quest is causing you to travel through many levels of
abstraction, most of which exist maily to prevent the "head hurt" of
thinking about them.
The ELF loader gets a program file in the elf format and decides what
part of it needs to be in memory, what addresses need to be re-located
to fit the program in "this" particular computer today- since the
"virtual" memory addreses may be different from last time.
The virtual memory is mapped onto physical memory and swapspace
dynamicaly. some part of the "process" can end up sitting in many
differnt Physical memory addresses if it get swaped in and out.
As I said in the other post, most of the variables end up on the stack
or the heap, which grow and shring dynamicaly as the program runs.
Each function you write ends up in a table like
_main
_foo1
_addUpTheBill
_WCaseSort
The program in C is always called MAIN, and the compiler adds in some
libaray code that inintialis the program and then calls main. (GUI
programs may have another libary that calls some other special program
name. All the functions have an address which the loader fixes up. the
linker sets this all up with Linking the different compiled c modules
and Libararys that make up the complete program.
The perfilled variables are also in the file and get loaded into memory,
space that is intened to hold non-prefilled variables is also assigned.
Everything can of course get swapped out at any time.
Normaly the ELF loader will provide some space for Maloc to use, but the
C libaray can use system functions ot get more. or even give some back.
The stack is just there and may be limited in size.
--
Charles MacDonald Stittsville Ontario
cmacd [ at ] TelecomOttawa [ dot ] net Just Beyond the Fringe
http://www.TelecomOttawa.net/~cmacd/
No Microsoft Products were used in sending this e-mail.