Need help understanding memory models, cpu modes and address translation

[Rajesh S R]

Hi Mulyadi,
Thanks for a nice explanation. A few nitpicks. Correct me if am wrong.

On Sat, Jul 16, 2011 at 9:45 AM, Mulyadi Santosa
<mulyadi.santosa at gmail.com>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 at gmail.com> 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.
>

PIC is used only for shared libraries (.so files). .o files have relocation
section specifically for that(of course also for undefined symbols linked
later). So, when a symbol's address is required, it wil be filled with 0x0
and a corresponding entry will be created in the Relocation Table. So, when
the final link editor links all .o files, it will readjust the addresses and
generate the final executable with a specific starting virtual address.


> 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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>



-- 
Rajesh S R
http://rajeshsr.co.cc/blogs/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110716/0ca133ae/attachment-0001.html