CODEWITHSUNDEEP
objective-cassemblyx86x86-64
A O
A O

Reputation: 5698

How to determine where this address comes from on 64-bit macOS application

So I'm currently debugging an issue, and trying to figure out how this could happen.

Here is the assembly for a method in the obj-c runtime, called objc_msgsend()

libobjc.A.dylib`objc_msgSend:
    0x7fff9084a0c0 <+0>:   testq  %rdi, %rdi
    0x7fff9084a0c3 <+3>:   je     0x7fff9084a140            ; <+128>
    0x7fff9084a0c6 <+6>:   testb  $0x1, %dil
    0x7fff9084a0ca <+10>:  jne    0x7fff9084a14b            ; <+139>
    0x7fff9084a0cd <+13>:  movabsq $0x7ffffffffff8, %r11
    0x7fff9084a0d7 <+23>:  andq   (%rdi), %r11
    0x7fff9084a0da <+26>:  movq   %rsi, %r10
    0x7fff9084a0dd <+29>:  andl   0x18(%r11), %r10d

I'm using Xcode's lldb to view the registers and addresses.

Here is the interesting output I get, when I first check out the registers at offset +0 (expected):

(lldb) register read
r11 = 0x00007fff74a940f0  (void *)0x00007fff74a94118: NSObject

After offset +13 (expected): 

(lldb) register read
r11 = 0x00007ffffffffff8

After offset +23 (not expected): 

(lldb) register read
r11 = 0x0000000100761138  (void *)0x0000000100761160: GTMOAuth2WindowController

And then if I po the registers at this point: 

(lldb) po $rdi
<GTMOAuth2WindowController: 0x6100001c2850>

(lldb) po &$rdi
0x000000010bc2b3b8

(lldb) po $r11
GTMOAuth2WindowController

(lldb) po &$r11
0x000000010bc2b3b8

So here's where I'm lost; after offset +23, what is that address when I register read? 0x0000000100761138. I would've expected it to have 0x6100001c2850, the location of the object from the dereference at +23

If I po $r11 it prints out the class name (which is expected because we're looking at the isa property), and if I print the location in memory for the pointer, it doesn't match the address in register read, it matches the address of %rdi (expected).

Upvotes: 1

Views: 122

Answers (1)

rob mayoff
rob mayoff

Reputation: 385650

That address in %r11 after <+23>, 0x0000000100761138, is the address of the class object that represents your GTMOAuth2WindowController class.

When you define a class at compile time (with @interface and @implementation), there's a special object at runtime that represents the class. In fact it's called a “class object” and is a real object just like all the objects you created. This means that the class object can itself respond to messages. When you said po %r11 after <+23>, the debugger sent the description message to the class object. The class object's description method returns the name of the class as an NSString, so the debugger printed the name of the class.

You can learn more about class objects here. The image link on that page is broken in Chrome but you can click it to see a pdf.

Upvotes: 2

Related Questions