Re: Need help understanding memory models, cpu modes and address translation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux