Need help understanding memory models, cpu modes and address translation

[Mulyadi Santosa]

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.

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