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