From mboxrd@z Thu Jan 1 00:00:00 1970 From: madhu.sk89@gmail.com (Madhu K) Date: Mon, 3 Oct 2016 10:42:15 +0530 Subject: Virtual Address Space In-Reply-To: References: <1475253618.1158.6.camel@riseup.net> Message-ID: To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org Hi All, Thank you so much for all your answers. Regards, Madhu On Sun, Oct 2, 2016 at 8:22 AM, Arshad Hussain wrote: > > On 30-Sep-2016, at 10:10 pm, Rom?n Mart?nez wrote: > > > Hi, > > > > I compile main.s and it generates main.o. With objdump I can see: > > > > 0000000000000000 <_start>: > > 0: b8 01 00 00 00 mov $0x1,%eax > > 5: bb 00 00 00 00 mov $0x0,%ebx > > a: cd 80 int $0x80 > > > > After link main.o it generates main. With objdump I now can see: > > > > 0000000000400078 <_start>: > > 400078: b8 01 00 00 00 mov $0x1,%eax > > 40007d: bb 00 00 00 00 mov $0x0,%ebx > > 400082: cd 80 int $0x80 > > > > So, linker generates virtual address, doesn't it? But why it starts at > 400078 and not in other any location? Is there any logic here? A virtual > address can start at 0? > > > The linker script would normally leave out some area and _not_ start from > 0. (although this is not > an absolute necessity ). It will pick up and valid virtual address and > assign start of .text,.bss and > .stack. This is possible because we now have virtual memory. And every > program thinks that it > has _all_ the memory for itself. So, 400078 is perfectly valid virtual > address space and linker > has chosen this for this executable. > > Also note that if the address space is getting shifted by little , this is > because of the KASLR > (layout randomisation) - If this is disabled then the linker would > generate the same virtual > address for all the executable every time. > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20161003/3b108c1b/attachment.html