Intel core i5, Ubunu 16.04
I’m reading about the memory paging here and now trying to experiment with it. I wrote a simple assembly program for getting Segmentation Fault and ran in gdb. Here it is:
section .text
global _start
_start:
mov rax, 0xFFFFFFFFFFFF0A31
mov [val], eax
mov eax, 4
mov ebx, 1
mov ecx, val
mov edx, 2
int 0x80
mov eax, 1
int 0x80
segment .bss
dummy resb 0xFFA
val resb 1
I assemble and link this into a 64-bit ELF static executable.
As far as I read each process has its own Page Table which cr3 register points to. Now I would like to look at the page table myself? Is it possible to find info about process page table in Linux?
Advertisement
Answer
You can see all the mappings your process has in /proc/PID/smaps. This tells you what you can access without getting a SIGSEGV.
This is not the same thing as your cr3 page table, because the kernel doesn’t always “wire” all your mappings. i.e. a hardware page fault isn’t always a SIGSEGV: the kernel page-fault handler checks whether your process logically has that memory mapped and corrects the situation, or whether you really did violate the memory protections.
After an mmap() system call, or on process startup to map the text / data / BSS segments, you logically have memory mapped, but Linux might have decided to be lazy and not provide any physical pages yet. (e.g. maybe the pages aren’t in the pagecache yet, so there’s no need to block until you try to actually touch that memory and get a page fault).
Or for BSS memory, multiple logical pages might start out copy-on-write mapped to the same physical page of zeros. Even though according to Unix semantics your memory is read-write, the page tables would actually have read-only mappings. Writing a page will page-fault, and the kernel will point that entry at a new physical page of zeros before returning to your process at the instruction which faulted (which will then be re-run and succeed).
Anyway, this doesn’t directly answer your question, but might be part of what you actually want. If you want to look under the hood, then sure have fun looking at the actual page tables, but you generally don’t need to do that. smaps can tell you how much of a mapping is resident in memory.
See also what does pss mean in /proc/pid/smaps for details on what the fields mean.
BTW, see Why in 64bit the virtual address are 4 bits short (48bit long) compared with the physical address (52 bit long)? for a nice diagram of the 4-level page table format (and how 2M / 1G hugepages fit in).