現在実行しているコンテキストはタスクコンテキストかそれとも非タスクコンテキストか分かるようなサービスがありますか

トロン系のOSは現在実行状態のタスクのIDを取得するサービス(get_tid )がありますが、現在実行しているコンテキストはタスクコンテキストかそれとも非タスクコンテキストか分かるようなサービスがありますか

  • 大聖さん、こんにちは。NoMaYと申します。

    sns_ctxというAPIで可能ではないですか?例えば、別スレッドの話題ですがNORTiでは以下の通りでしたよ。

    μITRON仕様準拠リアルタイムOS NORTi Version 4 カーネル編 ユーザーズガイド
    www.mispo.co.jp/document/no4guid.pdf
    画面コピー(2枚)


     

  • NoMaYさん、こんにちは。大聖です。ご回答していただいて、ありがとうございました。

    またCPU例外発生する直前、実行しているコンテキストはタスクコンテキストかそれとも非タスクコンテキストか分かるような方法がありますか

  • 大聖さん、こんにちは。NoMaYです。

    お使いのRTOSは具体的に何でしょうか?また、そのRTOSのドキュメントのURLも知りたいです。ドキュメントをひとりで読んでいただけでは見落としてしまったかも知れない箇所を、いわゆるダブルチェックしてみてはどうだろうかなぁ、ということなのですけれど。

  • NoMaYさん、こんにちは。大聖です。使用のRTOSはT-Kernel Ver1.00.00です。

  • 大聖さん、こんにちは。NoMaYです。

    これですか?これのドキュメントのURLはどこでしょうか?

    ソースコードダウンロード - T-Kernel 1.0
    www.tron.org/download/index.php?route=product/category&path=20

    サポートCPU一覧 - T-Kernelとは?
    www.tron.org/ja/tron-project/what-is-t-kernel/hwinfo

    T-Kernel、T-Kernel Standard ExtensionがサポートするCPU

  • NoMaYさん、こんにちは。大聖です。そうです。ありがとうございました。

  • 大聖さん、こんにちは。NoMaYです。

    T-Kernel 2.0のドキュメントのURLは見つかりましたけれど、、、

    T-Kernel 2.0仕様書
    www.tron.org/wp-content/themes/dp-magjam/pdf/t-kernel_2.0/html_ja/TEF020-S001-02.00.03_ja.html
     

  • NoMaYさん、こんにちは。大聖です。確かに現在手元にT-Kernel 2.0仕様書しか持っていません。それを調べても、CPU例外発生する直前に実行しているコンテキストはタスクコンテキストかそれとも非タスクコンテキストか分かるような方法を見付かりませんでした。

  • 大聖さん、こんにちは。NoMaYです。

    > CPU例外発生する直前に実行しているコンテキストはタスクコンテキストかそれとも非タスクコンテキストか分かるような方法を見付かりませんでした。

    以下のページを読んでみましたが、その情報を得るシステムコールは無いようですね。ところで、なぜ、それを知りたいのですか?多重割り込みが起きて、割り込みがネストしている状態かどうか、それを知りたい、ということだと思うのですが、なぜ、それを知りたいのですか?

    割込み管理機能
    www.tron.org/wp-content/themes/dp-magjam/pdf/t-kernel_2.0/html_ja/interrupt_management_functions_os.html

    tk_ref_sys - システム状態参照
    www.tron.org/wp-content/themes/dp-magjam/pdf/t-kernel_2.0/html_ja/system_management_functions.html#tk_ref_sys
     

  • NoMaYさん、こんにちは。大聖です。

    OSに絡む組込みシステムのソフトバグについて、開発者を一番悩ませるのはユーザーのところでシステムハングアップを起こし、且つ再現しにくいようなバグです。通常、致命的なバグはよくCPU例外を引き起こしますので、CPU例外処理でそのバグの発生した関数を自動特定するアルゴリズムを考えて、こちらでOS:T-kernel、CPU:SH7619の環境で検証して、バグ発生時の自動特定した結果をFLASHに書き込んで、システムを再起動してから、FLASHに書き込んだデータを読み出して、正確に特定できたことが確認できました。今そのアルゴリズムをよく考えるともし CPU例外発生する直前に実行しているコンテキストはタスクコンテキストかそれとも非タスクコンテキストかが分かったら、その特定処理アルゴリズムがもっと簡単にできると思います。

  • 大聖さん、こんにちは。NoMaYです。

    > 致命的なバグはよくCPU例外を引き起こしますので、CPU例外処理でそのバグの発生した関数を自動特定するアルゴリズムを考え

    >  CPU例外発生する直前に実行しているコンテキストはタスクコンテキストかそれとも非タスクコンテキストかが分かったら、その特定処理アルゴリズムがもっと簡単にできる

    きっと、この「CPU例外」は、不正命令実行例外とか、バスエラー発生例外とか、そういう特殊な(つまり普通の割り込みであるような例外を意味しているわけではない)例外のことですね。少なくとも、T-Kernel 2.0の標準仕様にそれを判別することが出来るシステムコールは無さそうですね。すみません、SH7619のアーキテクチャは分からないので、RXマイコンでの話をさせて貰えれば、私であれば、(RXマイコンであれば)以下のような方法を試してみるかと思うのです。

    RXマイコンでの判定方法

    (1) 不正命令実行例外とか、バスエラー発生例外とか、そういうCPU例外の(少なくとも)エントリの部分は自前で書く
    (2) そのエントリの部分では、例外発生時にスタックに退避されていたPSWのスタックポインタ種別フラグを調べる
    (2') なお、対象のRTOSでは、タスクコンテキストではユーザスタック、非タスクコンテキストでは割り込みスタック、を使うものとする
    (3) 上記(2)で調べた情報をもとに以下のように判別する
      退避されていたPSWのスタックポインタ種別 == ユーザスタック  ⇒ タスクコンテキストで、くだんのCPU例外が発生した
      退避されていたPSWのスタックポインタ種別 == 割り込みスタック ⇒ 非タスクコンテキストで、くだんのCPU例外が発生した

    RXマイコンでの話しになってしまって申し訳ありませんけれど、、、

    [追記]

    もしかしたら、今現在、SH7619で上のような処理を行っていて、それをRTOSのシステムコールを使って簡単化(実装し易く)出来ないだろうか?、という話だったのかも知れませんが、、、

  • NoMaYさん、こんにちは。大聖です。

    そうですね。お書いた(3)及び「追記」がもしOSのサービスとして提供できれば、バグ発生する場所の自動特定ルーチンの移植はより便利になるし、特定処理も簡単になると思います。しかしスタックに退避されたデータを使う場合は危険です。というのは経験により、CPU例外について数多くの場合は行列の限界を超えたライトによりスタックメモリが破壊されたわけです。そのためOSの方は別のルート(又は方法)で実現する必要だと思います。

  • 大聖さん、こんにちは。NoMaYです。

    私の方ではSH7619のアーキテクチャは分からないので同じ発想が使えるのかどうかは分からないですが、ただ、スタックに退避されていたPSWの値を調べるのは、CPU例外のエントリの箇所、つまりCPU例外が発生した直後、なわけなので、その時点で値が壊れてしまっている可能性はとても低いと私は思いますよ。もっとも、スタックオーバーフロー(いわゆるオーバーフローしたこと以外にも何らかの理由によりスタックポインタの値が壊れた)によってスタックポインタがメモリ領域外を指してしまっていて、そもそも正しい値が退避されていなかった、という可能性は別途ありますが、それはスタックポインタの値自体を記録に残しておくことで、後々での解析で有益な情報になるのではないかと思います。それに、CPU例外発生箇所を特定するには、そもそもスタック上のリターンアドレスの値を使うことになるのではないでしょうか。

    なお、CPUアーキテクチャによっては、(CPU例外に限らず)例外発生時のリターンアドレスやPSWを即スタックに退避するのではなく、CPU動作的には、まずは退避用のCPUレジスタに退避する、というものもありましたね。(V850がそうでした。)

    ここから先は、そのCPUアーキテクチャが分かっていない私ではちょっとアドバイス出来ないと思いますので、他の人からのリプライを待って頂けますか。

  • NoMaYさん、こんにちは。大聖です。

    ありがとうございます。私が間違いました。確かに ”。。。その時点で値が壊れてしまっている可能性はとても低い”です。