what happens before main()?
-
Hi,
I have a big library written in C++, in this lib there are several static-things that get initialised at the start of the Programm, even before the main() function is called.
So far so good, but the problem is - the program takes some time to start, and when I did some time-trackings to see where the time goes, I found out it takes already up to 3 seconds until my main() function is called.
But, since there are about 300-400 Files it would take forever to find the "bad" statics.. so, is there any way in Xcode to step trough the initialisation process? Like as if I'd put a breakpoint in the main() function and step forward.. but in the main method it's already to late :(
Aya~_______________________________________________
MacOSX-dev mailing list
<MacOSX-dev...>
http://www.omnigroup.com/mailman/listinfo/macosx-dev -
Hi!
To every C/C++ program, startup file is added - like /usr/lib/crt1.o
which does initializations. Since it was not compiled with -g, you
can't really step through it but you could find source for it (if
available) and compile it yourself and add it to your program instead
of standard crt*.o. In that case you could step through it.
Regards,
Ivan
P.S. You can check gcc/ld documentation which exact startup file is
linked to your program to be sure
On Apr 27, 2010, at 11:59 AM, Aya Koshigaya wrote:
> Hi,
>
> I have a big library written in C++, in this lib there are several
> static-things that get initialised at the start of the Programm,
> even before the main() function is called.
>
> So far so good, but the problem is - the program takes some time to
> start, and when I did some time-trackings to see where the time
> goes, I found out it takes already up to 3 seconds until my main()
> function is called.
>
> But, since there are about 300-400 Files it would take forever to
> find the "bad" statics.. so, is there any way in Xcode to step
> trough the initialisation process? Like as if I'd put a breakpoint
> in the main() function and step forward.. but in the main method
> it's already to late :(
>
> Aya~_______________________________________________
> MacOSX-dev mailing list
> <MacOSX-dev...>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>
-
I don't think that would help. The kernel hands off control to dyld (the dynamic linker), which is in charge of mapping all shared libraries, as well as running initializers (including C++ static initializers). dyld then jumps to crt1.o's entry point, which may do some further initialization before entering main().
Try looking at the dyld(1) man page. DYLD_PRINT_INITIALIZERS and DYLD_PRINT_STATISTICS might be enlightening
Shantonu
Sent from my MacBook
On Apr 27, 2010, at 3:42 AM, Ivan Ostres wrote:
> Hi!
>
> To every C/C++ program, startup file is added - like /usr/lib/crt1.o which does initializations. Since it was not compiled with -g, you can't really step through it but you could find source for it (if available) and compile it yourself and add it to your program instead of standard crt*.o. In that case you could step through it.
>
> Regards,
> Ivan
>
> P.S. You can check gcc/ld documentation which exact startup file is linked to your program to be sure
>
>
> On Apr 27, 2010, at 11:59 AM, Aya Koshigaya wrote:
>
>> Hi,
>>
>> I have a big library written in C++, in this lib there are several static-things that get initialised at the start of the Programm, even before the main() function is called.
>>
>> So far so good, but the problem is - the program takes some time to start, and when I did some time-trackings to see where the time goes, I found out it takes already up to 3 seconds until my main() function is called.
>>
>> But, since there are about 300-400 Files it would take forever to find the "bad" statics.. so, is there any way in Xcode to step trough the initialisation process? Like as if I'd put a breakpoint in the main() function and step forward.. but in the main method it's already to late :(
>>
>> Aya~_______________________________________________
>> MacOSX-dev mailing list
>> <MacOSX-dev...>
>> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>>
>
> _______________________________________________
> MacOSX-dev mailing list
> <MacOSX-dev...>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
-
On Tue, Apr 27, 2010 at 5:59 AM, Aya Koshigaya <Aya...> wrote:
>
> I have a big library written in C++, in this lib there are several static-things that get initialised at the start of the Programm, even before the main() function is called.
>
> So far so good, but the problem is - the program takes some time to start, and when I did some time-trackings to see where the time goes, I found out it takes already up to 3 seconds until my main() function is called.
>
> But, since there are about 300-400 Files it would take forever to find the "bad" statics.. so, is there any way in Xcode to step trough the initialisation process? Like as if I'd put a breakpoint in the main() function and step forward.. but in the main method it's already to late :(
I would try short-circuiting main() by adding a "return 0" at the top,
then profiling what's left with Shark or Instruments. That should give
you a report of not only what constructors are being called, but also
which ones are the major time sinks.
sherm--
--
Cocoa programming in Perl:
http://www.camelbones.org -
So things like __cxa_vec_ctor for global objects and __cxa_guard for
all statics are actually called by dyld? (I always thought it was done
by crt). But that shouldn't be a huge performance impact unless there
is a big number of unmapped libraries needed by application and/or
huge number of global objects or classes with static members. In
latter case it's a design issue, right?
BTW, dyld is not open sourced, I guess?
BR,
Ivan
On Apr 27, 2010, at 4:35 PM, Shantonu Sen wrote:
> I don't think that would help. The kernel hands off control to dyld
> (the dynamic linker), which is in charge of mapping all shared
> libraries, as well as running initializers (including C++ static
> initializers). dyld then jumps to crt1.o's entry point, which may do
> some further initialization before entering main().
>
> Try looking at the dyld(1) man page. DYLD_PRINT_INITIALIZERS and
> DYLD_PRINT_STATISTICS might be enlightening
>
> Shantonu
>
> Sent from my MacBook
>
> On Apr 27, 2010, at 3:42 AM, Ivan Ostres wrote:
>
>> Hi!
>>
>> To every C/C++ program, startup file is added - like /usr/lib/
>> crt1.o which does initializations. Since it was not compiled with -
>> g, you can't really step through it but you could find source for
>> it (if available) and compile it yourself and add it to your
>> program instead of standard crt*.o. In that case you could step
>> through it.
>>
>> Regards,
>> Ivan
>>
>> P.S. You can check gcc/ld documentation which exact startup file is
>> linked to your program to be sure
>>
>>
>> On Apr 27, 2010, at 11:59 AM, Aya Koshigaya wrote:
>>
>>> Hi,
>>>
>>> I have a big library written in C++, in this lib there are several
>>> static-things that get initialised at the start of the Programm,
>>> even before the main() function is called.
>>>
>>> So far so good, but the problem is - the program takes some time
>>> to start, and when I did some time-trackings to see where the time
>>> goes, I found out it takes already up to 3 seconds until my main()
>>> function is called.
>>>
>>> But, since there are about 300-400 Files it would take forever to
>>> find the "bad" statics.. so, is there any way in Xcode to step
>>> trough the initialisation process? Like as if I'd put a breakpoint
>>> in the main() function and step forward.. but in the main method
>>> it's already to late :(
>>>
>>> Aya~_______________________________________________
>>> MacOSX-dev mailing list
>>> <MacOSX-dev...>
>>> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>>>
>>
>> _______________________________________________
>> MacOSX-dev mailing list
>> <MacOSX-dev...>
>> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>
> _______________________________________________
> MacOSX-dev mailing list
> <MacOSX-dev...>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>
-
On Tue, Apr 27, 2010 at 9:38 AM, Ivan Ostres <iostres...> wrote:
> So things like __cxa_vec_ctor for global objects and __cxa_guard for all
> statics are actually called by dyld? (I always thought it was done by crt).
> But that shouldn't be a huge performance impact unless there is a big number
> of unmapped libraries needed by application and/or huge number of global
> objects or classes with static members. In latter case it's a design issue,
> right?
C++ static constructors and functions with the constructor attribute
are in fact run by dyld.
> BTW, dyld is not open sourced, I guess?
http://www.opensource.apple.com/source/dyld/dyld-132.13/
--Kyle Sluder
