osx - Why are the first 4 bytes of 64-bit addresses printed as 0x00000001? -


i'm looking @ disassembly of x86_64 code apple's otool. here's sample of disassembly, outputted otool:

0000000100055de4    movq    $0x00000000,%rax 

only last 4 bytes in offset, 00055de4, represent file address of instruction. can open hex editor , navigate 0x55de4 , movq instruction there.

however, noticed gdb works when include 8 bytes in address, including mysterious 1. break *0x0000000100055de4 works expected, while break *0x00055de4 never triggers.

every 64-bit binary have analyzed otool shows pattern. doesn't apply 32-bit addresses.

so, if 0x55de4 actual address, why otool , gdb use 0x0000000100055de4?

__pagezero, first load command in 64 bit mach-o binary, specifies segment size of 0x100000000 in virtual memory.

$ otool -lv binary

command 0       cmd lc_segment_64   cmdsize 72   segname __pagezero    vmaddr 0x0000000000000000    vmsize 0x0000000100000000 

when break *0x00055de4 breakpoint ends in segment of zeros, explains why it's never hit. 0x0000000100055de4 address of instruction (found @ 0x55de4 in binary) when loaded virtual memory.

for 32 bit binaries __pagezero size 0x1000, explains why pattern not apply.


Comments

Popular posts from this blog

java - Jmockit String final length method mocking Issue -

asp.net - Razor Page Hosted on IIS 6 Fails Every Morning -

c++ - wxwidget compiling on windows command prompt -