Why is there no MAIN? - VxWorks

This is a discussion on Why is there no MAIN? - VxWorks ; When using Tornado as the developing platform, why is there no main() function for us to create? And I've been used to programming and doing researches in this way, but still not quite understand why I only have to create ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Why is there no MAIN?

  1. Why is there no MAIN?

    When using Tornado as the developing platform, why is there no
    main() function for us to create?
    And I've been used to programming and doing researches in this
    way, but still not quite understand why I only have to create several
    tasks to execute.

  2. Re: Why is there no MAIN?

    I have the same problem.
    I guess there must exist a option to specify start function name or
    address.

  3. Re: Why is there no MAIN?

    Well... I am not quite sure about this specified-option-thing. Because
    in my opinion, when writing some tasks to implement, there would be an
    automatic creation for MAIN function inside Tornado environment. It
    would create the MAIN function based on the written tasks. However, I
    cannot understand the whole process in details.

  4. Re: Why is there no MAIN?

    Hello Helen,

    If you are using the Tornado product then you are using a VxWorks OS
    predating the 6.x version. Before the 6.0 version VxWorks only
    supported kernel execution environment for tasks and did not support
    processes, which is the traditional application execution environment
    on OS like Unix or Windows. Tasks have an entry point which is the
    address of the code to execute as a task. This address corresponds to
    a C or assembly function. It can be a symbol named "main" but there
    are C/C++ language assumptions about the main() function that are not
    supported in the kernel environment (in particular the traditional
    handling of the argc and argv parameters). Furthermore, prior to
    VxWorks 6.0, all tasks execute kernel code. You can picture the kernel
    as a common repository of code all linked together and then you'll see
    that you cannot have several symbols of the same name ("main") since
    this would create name collisions.

    Now this is accurate only if you link your application code to the
    kernel image. If you were to download your application code then the
    module loader will accept to load several modules each with a main()
    routine. However the last "main" symbol registered in the system
    symbol table is the only one you can access via the target shell. If
    you want to start tasks executing the code of one of the first loaded
    modules you'd have to use the addresses of the previous main()
    function. This is possible but not convenient. It is far more
    practical to give different names to the entry points of tasks (may be
    like "xxxStart" where "xxx" is a name meaningful for what the task is
    supposed to do).

    Starting with VxWorks 6.0 the OS supports a process environment. This
    means, among many other things, that you can have a traditional main()
    routine and that its argc and argv parameters are properly handled,
    and that the application code is executing in a context (user context)
    which is different from the kernel context, thus ensuring the
    isolation between application code (which can be flaky) and kernel
    code (which is not supposed to be flaky).

    I hope this helps,

    --
    PAD

  5. Re: Why is there no MAIN?

    On Aug 26, 6:20 am, "wangjinjian...@gmail.com"
    wrote:
    > I have the same problem.
    > I guess there must exist a option to specify start function name or
    > address.


    Look at the manual for the sp() copmmand and the taskSpawn() API.

    Also look at the manual for the lkup() and lkAddr() commands.

    Cheers,

    --
    PAD

  6. Re: Why is there no MAIN?

    On 26 אוגוסט, 17:13, helen_dan...@hotmail.comwrote:
    > Well... I am not quite sure about this specified-option-thing. Because
    > in my opinion, when writing some tasks to implement, there would be an
    > automatic creation for MAIN function inside Tornado environment. It
    > would create the MAIN function based on the written tasks. However, I
    > cannot understand the whole process in details


    There is no main(). Embedded OS doesn't work like that. Each CPU has a
    well-known address it knows to read instructions from, when it powers
    up. When compiling, you tell the Tornado compiler what is that
    address, based on the CPU. Then, you download your binary, power up,
    and vwalla.

  7. Re: Why is there no MAIN?

    On 827, 1ʱ56, PAD wrote:
    > Hello Helen,
    >
    > If you are using the Tornado product then you are using a VxWorks OS
    > predating the 6.x version. Before the 6.0 version VxWorks only
    > supported kernel execution environment for tasks and did not support
    > processes, which is the traditional application execution environment
    > on OS like Unix or Windows. Tasks have an entry point which is the
    > address of the code to execute as a task. This address corresponds to
    > a C or assembly function. It can be a symbol named "main" but there
    > are C/C++ language assumptions about the main() function that are not
    > supported in the kernel environment (in particular the traditional
    > handling of the argc and argv parameters). Furthermore, prior to
    > VxWorks 6.0, all tasks execute kernel code. You can picture the kernel
    > as a common repository of code all linked together and then you'll see
    > that you cannot have several symbols of the same name ("main") since
    > this would create name collisions.
    >
    > Now this is accurate only if you link your application code to the
    > kernel image. If you were to download your application code then the
    > module loader will accept to load several modules each with a main()
    > routine. However the last "main" symbol registered in the system
    > symbol table is the only one you can access via the target shell. If
    > you want to start tasks executing the code of one of the first loaded
    > modules you'd have to use the addresses of the previous main()
    > function. This is possible but not convenient. It is far more
    > practical to give different names to the entry points of tasks (may be
    > like "xxxStart" where "xxx" is a name meaningful for what the task is
    > supposed to do).
    >
    > Starting with VxWorks 6.0 the OS supports a process environment. This
    > means, among many other things, that you can have a traditional main()
    > routine and that its argc and argv parameters are properly handled,
    > and that the application code is executing in a context (user context)
    > which is different from the kernel context, thus ensuring the
    > isolation between application code (which can be flaky) and kernel
    > code (which is not supposed to be flaky).
    >
    > I hope this helps,
    >
    > --
    > PAD


    Thank u so much.

  8. Re: Why is there no MAIN?

    On 8月27日, 上午3时33分, ofe...@gmail.com wrote:
    > On 26 אוגוסט, 17:13, helen_dan...@hotmail.com wrote:
    >
    > > Well... I am not quite sure about this specified-option-thing. Because
    > > in my opinion, when writing some tasks to implement, there would be an
    > > automatic creation for MAIN function inside Tornado environment. It
    > > would create the MAIN function based on the written tasks. However, I
    > > cannot understand the whole process in details

    >
    > There is no main(). Embedded OS doesn't work like that. Each CPU has a
    > well-known address it knows to read instructions from, when it powers
    > up. When compiling, you tell the Tornado compiler what is that
    > address, based on the CPU. Then, you download your binary, power up,
    > and vwalla.


    Thank u so much.

+ Reply to Thread