CODEWITHSUNDEEP
macosprogram-entry-pointdynamic-library
Peeter Joot
Peeter Joot

Reputation: 8260

More info on functions like __dyld__dyld_start on MacOS

On MacOS I'm seeing a stack that looks like so (at the very top of the stack is a trap the code in question, but I want to understand how I get there)

(gdb) where
...
#4  0x0000000112fdefc8 in appLibInit::appLibInit ()
#5  0x0000000112fdef71 in __sti__$E ()
#6  0x00007fff5fc112f7 in __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE ()
#7  0x00007fff5fc0d20c in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#8  0x00007fff5fc0d1b0 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#9  0x00007fff5fc0d1b0 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#10 0x00007fff5fc0d1b0 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#11 0x00007fff5fc0d2f4 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()
#12 0x00007fff5fc038b4 in __dyld__ZN4dyld24initializeMainExecutableEv ()
#13 0x00007fff5fc06ea1 in __dyld__ZN4dyld5_mainEPK11mach_headermiPPKcS5_S5_ ()
#14 0x00007fff5fc01695 in __dyld__ZN13dyldbootstrap5startEPK11mach_headeriPPKcl ()
#15 0x00007fff5fc0103a in __dyld__dyld_start ()
#16 0x0000000100000000 in ?? ()
#17 0x0000000000000001 in ?? ()

The function appLibInit::appLibInit is a C++ constructor for a global object in our code, so I'm guessing I'm in pre-main code of some sort, probably processing all the shared libraries that are linked to (oddly the code in question is not something that we expect we are linked to, unless it is being dragged in by something else).

The mac c++filt doesn't seem to decode these __dyld prefixed symbols.

Does anybody know of some docs that describe the MacOS process startup sequence, that would possibly give me a bit more of a clue what's going on here?

Upvotes: 1

Views: 473

Answers (1)

user149341
user149341

Reputation:

The source to dyld is available online:

http://www.opensource.apple.com/source/dyld/

You can decode the mangled symbol names by simply removing the __dyld prefix. The prefix is presumably added to prevent conflicts with user code that happens to define the same C++ functions (for instance, if you're compiling parts of dyld yourself).

What you're looking at, more generally, is library load and initialization. A dynamic library can declare that a function should be run when it is loaded; it looks like that's happening here for your appLibInit::appLibInit(). (This can end up happening before main(), if the library is loaded by the main binary.)

One way this might be happening in C++ would be if you declare any objects globally which have constructors.

Upvotes: 1

Related Questions