x86-64

The user virtual address space for x86-64 with Linux is 47 bit long. Which essentially means that Linux can map a process with around ~128 TB virtual address range. However, what confuses me that x86-64 architecture supports ISA defined 4-level hierarchical page table (arranged as radix-tree) for each process. The root of the page table can only map up to 512 GB of contiguous virtual address space. So how Linux can support more than 512GB of virtual address range? Does it uses multiple page tables for each process? If yes, then for a process what should the CR3 (x86-64's register to contain

I have an application which periodically (after each 1 or 2 seconds) takes checkpoints by forking itself. So checkpoint is a fork of the original process which just stays idle until it is asked to start when some error in the original process occurs. Now my question is how costly is the copy-on-write mechanism of fork. How much is the cost of a page fault trap that will occur whenever the original process writes to a memory page (first time after taking a checkpoint that is), as copy-on-write mechanism will make sure that it gives the original process a different physical page than the

I am trying to understand assembly to be able to solve a puzzle. However I encountered the following instructions: 0x0000000000401136 <+44>: cmpl $0x7,0x14(%rsp) 0x000000000040113b <+49>: ja 0x401230 <phase_3+294> What I think its doing is: The value of 0x14(%rsp) is -7380. According to my understanding cmpl compares unsigned. Also the jump is performed. So can it be that (unsigned)-7380 > 7 (unsigned)7380 > 7--> jump I actually don't want it to jump. But is this the correct explanation or not? Am I flipping arguments? Also if you have any advice about how to manipulate this jump! According to

Trying to compile non-PIC code into a shared library on x64 with gcc results in an error, something like: /usr/bin/ld: /tmp/ccQ2ttcT.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC This question is about why this is so. I know that x64 has RIP-relative addressing which was designed to make PIC code more efficient. However, this doesn't mean load-time relocation can't be (in theory) applied to such code. Some online sources, including this one (which is widely quoted on this issue) claim that there's some inherent limitation

This question was put on hold as too broad, presumably because of the research I included in an effort to "show my work" instead of asking a low effort question. To remedy this, allow me to summarize the entire question in a single sentence (credit to @PeterCordes for this phrase): How do I efficiently call (x86-64) ahead-of-time compiled functions (that I control, may be further than 2GB away) from JITed code (that I am generating)? This alone, I suspect, would be put on hold as "too broad." In particular, it lacks a "what have you tried." So, I felt the need to add additional information

Let's consider the following program, which computes an unsigned square of the argument: .global foo .text foo: mov %rdi, %rax mul %rdi ret This is properly compiled by as , but disassembles to 0000000000000000 <foo>: 0: 48 89 f8 mov %rdi,%rax 3: 48 f7 e7 mul %rdi 6: c3 retq Is there any difference between ret and retq ? In long (64-bit) mode, you return ( ret ) by popping a quadword address from the stack to %rip . In 32-bit mode, you return ( ret ) by popping a dword address from the stack to %eip . Some tools like objdump -d call the first one retq . It's just a name, the instruction