[Fwd: Re: feedback requested on proposed new directive]
Rosimildo da Silva
rdasilva at connecttel.com
Tue Aug 29 20:51:05 UTC 2000
From: Charles-Antoine Gauthier <charles.gauthier at nrc.ca>
To: rtems-users <rtems-users at oarcorp.com>
Sent: Tuesday, August 29, 2000 11:07 AM
Subject: Re: [Fwd: Re: feedback requested on proposed new directive]
> Yes yes yes! Do get rid of main in the startup code.
We all know that the main() function used by RTEMS' startup
is a major pain. I am ready to celebrate with six pack beer
when it goes away. :-)
> > Why not call main() from within the init_task ?
> > Global Ctor would be called from inside this init task.
> But this is a change in semantics. It requires that there be only one
> init task for all APIs In fact, it removes the need for applications to
> supply init tasks, unless the application supplied init tasks are just
> created automatically by the new RTEMS-supplied init task, the one you
> call init_task.
Well, I do not think and changes much.
Why applications should supply init_tasks, anyway. ???
>From a programmer standpoint, I expect the system to call my application
entry point, main(), and I'll do the initialization of my specific tasks
Just like Linux, WIndows, OS/2, DOS, ( put your OS here ).
The init_task() should be some kind of "super duper task". It is a RTEMS,
POSIX, iTron task at same the time. It should work with any API.
> Was this discussed? Did I miss some threads?
yes, we discuss this before, .....
> > start ---> boot_card() ----> start multi-task --> init_task() -->
> > init()/fini()
> I am wondering if we need to register the exception tables earlier that
> this? In which case, we must re-implement to functionality of _init to
> call the __register_frame_info earlier, and call __do_global_ctors once
> multitasking has started up.
> If you don't call __register_frame_info early, then no user supplied
> initialization code should throw an exception. This may not be a
> significant limitation, but it should be documented.
I do not think that any user code would run until the main() is called....
so we might be ok.
> Yes, but now one must ask: where does argc and argv come from? This is
> an issue for me at this time. We got dejagnu working and have managed to
> run most of the libgcj regression testsuite on our targets. Except that
> it looks like the mauve test executables expect arguments. Doh! I should
> I get these arguments into the target? I have several possibilities in
> mind, but I would like to see RTEMS implement some documented approaches
> to do this. I could then code up the one that makes the most sense into
> the expect scripts.
It could be provided along with the main() function. The init_task
would use the global values. If you do not provide them, along with
your main() function, the link would use the module in the library
with the default values.
/* default_args.c */
char *global_argv =
int global_argc = sizeof( global_argv ) / sizeof( global_argv[ 0 ] ) ;
/* end default_args.c */
int main( int argc, char **argv )
More information about the users