Hello Vaibhav... What you asked, is something really difficult to summarize in short...but let me try... On Sat, Jul 16, 2011 at 10:14, Vaibhav Jain <vjoss197@xxxxxxxxx> wrote: > Hi, > Thanks a lot for all the links! > I read the two articles below by Gustavo but I am still very confused about > segmentation. One of the articles below says that > the segments in virtual address space are different from 'intel-style > segments' whereas I used to think of them as being the same. I am not really sure what segments in virtual address space really means. What we have in virtual address space is AFAIK kernel space and user space. User space, is a space where OS put user and data from your casual programs (e.g your games, your word processors etc). Assuming it's in x86 32 bit, the range in virtual address is between address 0 and slightly under 3 GiB. Whereas kernel space, is a space where OS put its own data and code (i.e interrupt handler, system call handler, page tables). Again in x86 32 bit, it lies between 3 GiB up to 4 GiB. > Could somebody please state the difference clearly for me and explain how > these two work together. I would > really appreciate if someone could explain the whole chain from generation > of addresses by compiler and then translation of > those addresses in case of Segmentation working along with Paging. when you generate object code from your source code (let's say in C) using gcc, first your code and variables (data) are turn into Position Independent Code. It means, it is just an offset. If there is an offset, surely we need base address, right? But not at this object (resulting in .o) stage. Then in reach producing final ELF binary (executable). Using known standart ELF rule, those offset are turn into final final address. So let's, code are placed starting at 0x080499f0 and so on. When that binary is loaded into memory, loader (ld.so) take that information and use it as a clue on where to put the code and data. Using standart mmap() syscall, memory area is reserved and data/code is loaded there. The exception is stack, where it is allocated dynamically (and grows down, for Intel arch) starting at the upper limit of user space (near 3 GiB). The new feature, called PIE (position independent code) allow loader to do further address reorganization. So instead of let's say taking 0x080499f0 for start of code segment for granted, it can relocate it to another address (but still in user space). However, in order to do that, every addresing done by the code must be compiled differently, so instead using constant address, now it uses combination of base register and offset AFAIK. Code runs, data addressed, they are all under virtual address. But memory is pointed using real address. Here comes the work of MMU (Memory Management Unit). With the help of tables of address translation called page tables, virtual address is translated into real address. The detail is left for you for further research. But enough to say it works like lookup table, e.g "12" in virtual address could means real address 10012 and so on. Please notice that continous address in virtual address doesn't neccessarily means continous address in real address e.g 12-20 in virtual address could means 10012 up to 10016 then 40017 up to 40020. Getting clearer now? :D -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
