How to obtain mach-O symbol stub information?

[mstange]

I'm trying to look up address 0x77d58 in the arm64 object in this libmozglue.dylib.

This address was sampled by a profiler. According to Hopper, it is inside a symbol stub for OSSpinLockUnlock:

        ; ================ B E G I N N I N G   O F   P R O C E D U R E ================


                     imp___stubs__OSSpinLockUnlock:        // OSSpinLockUnlock
0000000000077d54         nop
0000000000077d58         ldr        x16, #_OSSpinLockUnlock_ptr                 ; _OSSpinLockUnlock
0000000000077d5c         br         x16                                         ; _OSSpinLockUnlock
                        ; endp

Is there a way I can get the address and name for imp___stubs__OSSpinLockUnlock using object?

[bjorn3]

Object is an object file parsing crate. The mach-O files don't directly encode at which offset in the __stubs sections which symbol exists. Hopper likely uses heuristics to match them. This stack overflow question seems at least somewhat useful: https://reverseengineering.stackexchange.com/questions/8163/in-a-mach-o-executable-how-can-i-find-which-function-a-stub-targets#8170

[philipc]

As stated in the link from bjorn3, you'll need to parse more load commands for this. object doesn't currently parse all the Mach-O load commands, but support for that would be welcome. src/macho.rs should already have their definitions.

It might also make sense to add a method to Object to expose these (or maybe extend Object::imports, not sure). For example, it can be useful to know about relocations for symbols in ELF PLT stubs, and the address of the PE IAT entry for an import.

[mstange]

Thank you! It'll probably be a while before I'll have time to pursue this, but now I know where to start looking.

[philipc]

BTW, it doesn't appear that dump_syms uses this crate (instead it uses symbolic and goblin).

[mstange]

I've made some progress on this now. Code is here: https://github.com/mstange/macho-stubs/blob/6dbb225e43002afe97a539682bbba731029c0fc9/src/main.rs#L140-L298
This gives me the addresses in the __DATA segment for the pointers that are updated. But it doesn't give me the addresses in the __stubs section of the stub functions that read those pointers. bjorn3 is probably right and I do need some heuristics to match them up.