Re: Always provide exit() & friends prototypes.

[Sergei Organov <osv at javad dot com>]

Jonathan Larmour <jifl@eCosCentric.com> writes:

> Sergei Organov wrote:
>> Jonathan Larmour <jifl@eCosCentric.com> writes:
>>> Sergei Organov wrote:
>> [...]
>>>> Well, let's then think why there is no definition in the first
>>>> place? eCos has the definition for exit(), and in fact it in no
>>>> way depends
>>>> on existence of some thread called "main" that invokes "main()"
>>>> routine, so exit() existence should not depend on the
>>>> presence/absence of the libc_startup package.
>>> I think you are reading too much into the name of libc_startup.
>>
>> Sorry, but in fact I don't read anything into the name. I only wish to
>> get rid of the "main" thread. The only way to get rid of "main" thread
>> I've found is to remove libc_startup package, and that's what I
>> did.
>
> As I mentioned in the last mail, have you tried disabling
> CYGSEM_LIBC_STARTUP_MAIN_THREAD?

I somehow missed this one, sorry (it's due to Friday evening, I
think). I'll definitely try it.

>
>> Though if one provides none and somehow still links in the libc.a,
>> they will be taken from newlib, that could be surprising.
>
> There should be no newlib in your toolchain, at least if you are using
> the ones from the eCos FTP site (or which are built following the same
> instructions).

I'm using toolchain for SPARC built by Gaisler Research, -- see details
below. Do I remember correctly that old official toolchains did contain
newlib as well? Anyway, that's not a problem for me.

>> [...]
>>> I think a separate package would be overkill. But I wouldn't be averse
>>> to more flexibility in the configuration within the libc_startup
>>> package.
>>
>> After this discussion, I see this as the only *real* fix that we might
>> agree upon. Unfortunately I'm not enough familiar with configuration
>> system to do the required changes both fast and correctly.
>
> And unfortunately I am (as ever) very busy, and this would be a
> relatively low priority. Perhaps submit it as a bug at
> http://bugs.ecos.sourceware.org so the issue is not forgotten about.

Yeah, I see. I'll first try the CYGSEM_LIBC_STARTUP_MAIN_THREAD that
I've somehow missed, then we will see...

>> BTW, even though I provide my own cyg_user_start(), the main thread
>> provided by libc_startup runs anyway and by default invokes empty main()
>> routine. After main() returns, it calls atexit handlers, some of which
>> happen to be destructors(!) of global/static variables registered by
>> GCC, leaving the rest of application to work with destroyed state. It
>> took me quite a while to figure this out. Maybe it's safer to just sleep
>> in the default main() when the kernel is present, or provide none?
>
> That's a new one to me. What GCC is this, and for what target?

$ /opt/sparc-elf-3.4.4/bin/sparc-elf-gcc -v
Reading specs from /opt/sparc-elf-3.4.4/lib/gcc/sparc-elf/3.4.4/specs
Configured with: ../gcc-3.4.4/configure --target=sparc-elf --prefix=/opt/sparc-elf-3.4.4 --with-gnu-as --with-gnu-ld --verbose --enable-languages=c,c++ --disable-shared --disable-nls --with-newlib --with-cpu=leon
Thread model: single
gcc version 3.4.4
$

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.

Even though the above C++ construct is not thread-safe it's sometimes
useful during initialization when multi-threading is not started yet.

Even if user app is plain C, silently calling atexit() seems to be
dangerous as user application code might still register something with
atexit() at startup.

> Unfortunately we have to have a default main, otherwise in our many
> templates and configurations with the libc_startup package included,
> any eCos test programs that don't use main() will not link.

Yeah, I see. Maybe Cyg_Thread::self()->suspend() in the main() when
there is kernel there will help.

-- 
Sergei.