0

When we create a child process by using the system call fork(), address space of parent process is copied to child process. The code below demonstrates this clearly.

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>


int main(void){

    int *mem = (int*)malloc( sizeof(int) * 1 );
    pid_t pid = fork();

    if( pid == 0 ){ // child process
        printf("Child address = %ld\n", mem);
    }
    else{ // parent process
        printf("Parent address = %ld\n", mem);
    }

    return 0;
}

However, this is virtual address space. In other words, the addresses printed by this code are virtual addresses.

What I am wondering is whether there is a chance that we can obtain physical address by virtue of virtual addresses?

I suppose that there is a base register which stores start physical address of running process. If I sum this virtual address with the value of base register, I can find physical address of that variable. Is this true ?

1
  • one continuous virtual address block can be assembled from separate chunks of physical memory. so I don't think that's true. Look at this picture from Wikipedia
    – A.B
    May 21, 2018 at 20:28

2 Answers 2

1

Yes, all that the process itself sees directly is just virtual addresses.

On your usual paging system there's no "base register", since the virtual-to-physical address mapping happens by pages, which need not be in-order. (e.g. you can have virtual page 1 at physical page 4563, but virtual page 2 at physical page 2413.) See e.g. the image on the Wikipedia page on Page tables.

I don't think a process can directly access it's page tables, but it appears that Linux exports them through /proc/<pid>/pagemap. The kernel documentation for that is at Documentation/vm/pagemap.txt. There's also another question on reading the pagemap: Viewing pagetable for a process.

1

There is no guarantee that a particular virtual address maps to a unique physical address. There is no guarantee that a particular virtual address maps to any physical address. There is no guarantee that any mapping between a virtual address and some physical address will remain consistent for any interesting length of time.

So, your question really doesn't reflect the way virtual memory works. You do work in terms of virtual addresses. The kernel can fiddle with things like the MMU however and whenever it likes to change what points where, so even if you knew some physical address, you could never use it for anything. Even if you got enough information out of the visible kernel controlling your process to infer where something might be, you can't know for sure that you aren't in some VM, and there's a whole other layer of indirection on top of what you see -- such that what you think is a physical address is actually just the virtual address inside some VM host software.

Your virtual addresses are grouped into pages. The MMU is programmed with some page tables so it has some mapping. If there is a simple register with the offset inside the MMU, you have no way of getting it out of the MMU, because it isn't a CPU register that is part of the ISA. (And on older machines, the MMU was a completely separate physical chip from the CPU.) The only thing you can do is read through a bunch of MMU documentation for you architecture, and get access to the kernel's pagetable configuration and step through that stuff to "emulate" the behavior of the MMU on certain inputs. The CPU itself isn't even (visibly/directly) aware of the indirection.

So, what is it that you actually want to do?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .