Re: Always provide exit() & friends prototypes.

[Sergei Organov <osv at javad dot com>]

Jonathan Larmour <jifl@eCosCentric.com> writes:
> Sergei Organov wrote:
>>
>> Yeah, I see. I'll first try the CYGSEM_LIBC_STARTUP_MAIN_THREAD that
>> I've somehow missed, then we will see...
>
> It's possible you might have to enable CYGSEM_LIBC_STARTUP_MAIN_OTHER
> as well, I'm not sure. Let me know about any problems (preferably with
> patches ;-)).

OK, hopefully I'll have some spare time for this tomorrow.

>
>> It seems that GCC uses atexit() facility to register destructors for
>> static objects found inside functions, like this:
>>
>> void foo() {
>>   [...]
>>   static SomeClassWithCtor_Dtor var;
>>   [...]
>> }
>> As 'var' should be initialized at the first pass through the function,
>> GCC registers a function calling destructor with atexit() after
>> constructor of the variable is actually called.
>
> Interesting - it doesn't do this normally. I believe this may be a
> property of the toolchain. I do vaguely recall there's some option
> within GCC (i.e. when you do a GCC port) for whether to use a .dtor
> section for global destructors, or atexit. So far, it's always been
> .dtor.

I don't think it depends on the toolchain being used. Please note that
for the above pattern GCC can't put call to constructor into .ctors, as
the constructor should not be called at startup. For similar reason it
can't put destructor into .dtors, as it doesn't know if destructor needs
to be called at all.

Anyway the toolchain still mostly generates .dtors sections, but for
files that contain the above pattern it has call to atexit() after the
call to the constructor. It registers function with name "__tcf_0" that
contains just a call to the destructor, and this destructor is not put
into .dtors of this file.

-- 
Sergei.