On Sat, Jul 16, 2011 at 9:45 AM, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote: > 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. > I think in linux all segments(__USER_CS,__USER_DS,__KERNEL_CS,__KERNEL_DS) starts at 0x00000000.So offset fileld of logical address always coincide with linear address.So in case of Linux, segmentation is some dumb kind of thing.can any one correct me if i am wrong. > 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 > _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
