Messages in this thread |  | | From | "Chris Swiedler" <> | Subject | RE: large memory support for x86 | Date | Thu, 12 Oct 2000 15:22:44 -0400 |
| |
> > Am I reading this correctly--the address of the main() function for a > > process is guaranteed to be the lowest possible virtual address? > > > > chris > > > > It is one of the lowest. The 'C' runtime library puts section > .text (the code) first, then .data, then .bss, then .stack. The > .stack section is co-located with the heap which can be extended > by setting a new break address. > > When a process is created, the lowest address is the entry point of > crt0.o _init. We can see where that is by: > > Script started on Thu Oct 12 14:25:35 2000 > # cat xxx.c > > extern int _init(); > main() > { > printf("_init is at %p\n", _init); > } > > # gcc -o xxx xxx.c > # ./xxx > _init is at 0x804838c > # exit > exit > Script done on Thu Oct 12 14:25:51 2000 > > That said, remember that in Unix, the 'C' rutime library exists in the > lower portion of the .text section. So your code's virtual address space > starts above that address space. This is MMAPed so everybody gets > to share the same pages. In this way, you don't all have to keep a > private copy of the 'C' runtime library.
User-process virtual addresses have no direct relation to physical addresses, right? So why does the process space start at such a high virtual address (why not closer to 0x00000000)? Seems we're wasting ~128 megs of RAM. Not a huge amount compared to 4G, but signifigant. Is that space used (libc can't be that big!) or reserved somehow?
Another question: how (and where in the code) do we translate virtual user-addresses to physical addresses? Does the MMU do it, or does it call a kernel handler function? Why is the kernel allowed to reference physical addresses, while user processes go through the translation step? Can kernel pages be swapped out / faulted in just like user process pages?
Sorry to pounce on you with all of these questions. I've read up on this stuff but can't always find answers...
thanks-- chris
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |