This is the mail archive of the ecos-patches@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Always provide exit() & friends prototypes.


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. After that suddenly eCos itself stopped to compile (your patch has
fixed that bit, though I'm afraid the problem may re-occur if I enable
some other packages), and then compilation of my application breaks due
to absence of declarations of exit() and friends.

So the question is "How do I get rid of the "main" thread and still have
my precious exit()"? As currently there seems to be no way, I'm forced
to use the work-around presented in my initial patch. This works for me
as I provide my own exit() & abort() anyway. Though if one provides none
and somehow still links in the libc.a, they will be taken from newlib,
that could be surprising.

[...]
> 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.

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?

-- 
Sergei.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]