• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 5 answers
  • Subscribers 100 subscribers
  • Views 596 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM5746: Exit and abort call issues

rei
Mastermind 6155 points
Part Number: AM5746
Other Parts Discussed in Thread: SYSBIOS

Hi,

My customers worry about calling exit()/abort() function in SYSBIOS.

When exit()/abort() called via system_exit()/system_abort(), we can notice abnormally.

However, if exit()/abort() function are called directly, we can't notice abnormally.

The following summary is about each call sequence.

calling_seq.pdf

■Version
AM574x
CCS v8
GCC GNU v6.3.1(Linaro)
HW IDK574xEVM
SW pdk_am57xx_1_0_11
　bios_6_76_00_08
XDCTools 3.50.3.33

Regards,
Rei

  • 0
    TI__Mastermind 30830 points

    Rei,

    System_exit() invokes BIOS-unique atexit functions that aren't invoked properly when calling exit() directly.

    When you say "no one can detect that a problem has occurred.", what does that mean? How does your system detect a problem?

    Calling exit() and/or abort() directly bypasses the flushing of the SysMin output buffer that occurs when System_abort() is called. Is that the issue?

    Alan

  • 0 in reply to Alan DeMars
    Mastermind 6155 points

    Hi Alan,

    It's different. My explanation is bad. Sorry…

    Roughly,
    In the case of system_exit()/system_abort(), We can detect anomalies using the HOOK. However, If there are cases where exit() executed directly, we can't discover anomalies.

    For example, when exit()/abort() is called suddenly, suppose infinite loop occurs on Task Context. Despite being deadlocked, we can't detect it.
    Customers hope to avoid this case and they worry about the case where exit()/abort() is called directly.
    (When called from system_exit () / system_abort (), there is no problem because it can HOOK. )

    Regards, Rei

  • 0 in reply to rei
    TI__Mastermind 30830 points

    Rei,

    Can this be addressed by your application adding its own "atexit()" function?

    Alan

  • 0 in reply to Alan DeMars
    Mastermind 6155 points

    Hi Alan,

    Thank you for your reply. I told then about atexit() function. They are checking it.

    (I think this is difficult to confirm ...)

    Is there a case where exit () / abot () is called without going through system_exit () / system_abort ()?

    If not, we don't need to prepare atexit() function.

    Regards, Rei

  • 0 in reply to rei
    TI__Mastermind 30830 points

    Rei,

    The SYS/BIOS code base only invokes either System_exit() or System_abort().

    But nothing is stopping user code from calling exit() or abort() directly.

    Alan

  • 0 in reply to Alan DeMars
    Mastermind 6155 points

    Hi Alan-san,

    ”SYS/BIOS doesn't call exit()/abort() directly (it mean all via system_exit()/system_abort()).”
    My customers concern was removed, thank you very mach.

    However, they are either thinking about industrial communications in future, and are concerned about cases where 3rdparty software call exit()/abort(). So customers tried to HOOK exit()/abort() using the atexit().

    When exit() is called from abort(), it can't HOOK.

    ->Explanatory material
    20191009b_exit_abort().pdf

    Customers now think that using " symbol overriding function" is the easiest implementation.
    Are there any formal TI procedure?

    Regards,
    Rei

  • 0 in reply to rei
    TI__Guru* 96960 points

    rei said:
    Customers now think that using " symbol overriding function" is the easiest implementation.
    Are there any formal TI procedure?

    We're checking with the compiler team on this.

  • 0 in reply to ToddMullanix
    TI__Mastermind 30830 points

    A method suggested by the compiler team is to simply add a custom implementation of abort() to the user's application.

    That implementation should get used rather than the one supplied by the RTS library.

    Alan

  • 0 in reply to Alan DeMars
    Mastermind 6155 points

    Hi Alan,
    My customers said that they would implement abort function himself and HOOK. Thank you very much!

    However, they are distrusted because OS(SYSBIOS) can't detect when calling exit/abort function. Customers need to hook exit/abort function in OS to stop their application and system safely.

    They think that OS assumed HOOK exit/abort from the following description.

    C:/ti/gcc-arm-none-eabi-6-2017-q1-update/share/doc/gcc-arm-none-eabi/html/libc/exit.html
    -Supporting OS subroutines required: _exit.

    C:/ti/gcc-arm-none-eabi-6-2017-q1-update/share/doc/gcc-arm-none-eabi/html/libc/abort.html
    -Supporting OS subroutines required: _exit and optionally, write.

    Currently, (From 20191009b_exit_abort().pdf)
    In the case of 4, the HOOK function registered with atExit () is not called from exit (). (Only infinite loop) Undetectable

    There is no way to notify the user's application. Could you support it in the future with update of sysbios?

    My customers want to make TI-RTOS better!

    Regards,
    Rei

  • 0 in reply to rei
    TI__Mastermind 30830 points

    Rei,

    This is the first time the issue has come up.

    We don't provide this functionality for any of the other tool chains either (TI, IAR, TI-CLANG).

    I filed an internal Feature Request (SYSBIOS-1217) to log this request.

    The proposal will be reviewed as part of our normal quarterly release review process.

    Alan

  • 0 in reply to Alan DeMars
    Mastermind 6155 points

    Hi Alan,

    Thank you very much!