Open alexchandel opened 10 years ago
Actually, look at the disassembly for "jmp *$0" :: "m"(self.eip), "{esp}"(self.esp)
that I found in main:
...
10b56: 89 44 24 34 mov DWORD PTR [esp+0x34],eax
10b5a: 89 cc mov esp,ecx
10b5c: 31 c0 xor eax,eax
10b5e: 31 d2 xor edx,edx
10b60: ff 64 24 34 jmp DWORD PTR [esp+0x34]
...
Notice how esp
is clobbered before the new instruction pointer is loaded. Guess what [esp+0x34]
is then? Page Fault. Instead, load eip
first:
asm!("xor edx, edx
jmp DWORD PTR $0" :: "{eax}"(self.eip), "{esp}"(self.esp) :: "volatile", "intel");
Building on OS X gives me the page fault error: "
Accessed 0xc0000014 from 0x1196c
".The instruction pointer is different every time I build, but the
cr2
is always0xc0000014
. The stack starts at0xc0000000
, .However, I've noticed that the instruction pointer
0x1196c
points to inside"000118fa <exception_handler_asm>:"
Shouldn't
Context::save()
save the instruction address from before the interrupt, or does the page fault actually occur in the exception handler?I've noticed that subtracting different values from esp changes the
cr2
value slightly.Also in case it's related, I'm curious how_binary_initram_elf_start
gets resolved. It's declared as an externalu8
, and never referenced again. The closest thing I can find is the_start
label inmodule.asm
. But in the disassembly, I find this unfamiliar code:Edit: figured out the linker creating the
_binary_initram_elf_start
section. The actual jump location is0x08048060
, which first appears ininitram.elf
. This error still doesn't make sense, sincemodule.asm
doesn't access the stack.