This is the mail archive of the
ecos-patches@sourceware.org
mailing list for the eCos project.
Re: Always provide exit() & friends prototypes.
- From: Jonathan Larmour <jifl at eCosCentric dot com>
- To: Sergei Organov <osv at javad dot com>
- Cc: ecos-patches at ecos dot sourceware dot org
- Date: Fri, 05 Oct 2007 17:38:45 +0100
- Subject: Re: Always provide exit() & friends prototypes.
- References: <87ir5w43y0.fsf@javad.com> <46FBCC7D.7090107@eCosCentric.com> <87641w3uba.fsf@javad.com> <46FC039E.5090309@eCosCentric.com> <87ve9mylwq.fsf@javad.com> <47064DD6.4010004@eCosCentric.com> <87k5q1zgbn.fsf@javad.com>
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?
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 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.
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?
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.
Jifl
--
eCosCentric Limited http://www.eCosCentric.com/ The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
>>>> Visit us on stand 810 at The Embedded Systems Show 2007, NEC <<<<
>>>> Oct 17-18 Birmingham, UK http://www.edaexhibitions.com/ess/ <<<<
------["The best things in life aren't things."]------ Opinions==mine