(toppers-users 3441) Re: タスクスタックの状況を確認するためのシステムコール実現の御提案

[SHUKUGUCHI Masahiro]

コメントありがとうございます。

動的検出方法をハードウェアまたはRTOS以外の責務にすることに依存はあり
ません。しかし、規模（開発、予算等）や用途（要求される安全性等）によ
り、それが適わぬこともあります。その点で、検討した際のソリューション
として、これらの議論がなされていてもよいと思います。

（瑣末に）反論すると
> しかし，タスク例外はタスクコンテキストで実行されますので，スタックが
> 溢れるかもという時に使うのは危険かもしれません．
であれば、スタックオーバーフォロー寸前でのタスク例外処理ルーチンが呼び
出されるシチュエーションは考慮すべきことですので、実装としてタスク例外
処理ルーチンのスタックを別に確保して安全性を高める方式はあると思います。

そうなると、「タスクコンテキストで動作する」意義の議論が必要ですね。

さて、一方
> そうでない場合もソフトウェア割込みなど使って非タスクコンテキストに
> 移すほうが，より安全ではないでしょうか．標準化もしやすそうですし．

はい。仰せのとおりです。
先のメールの議論を読み返せば、途中を端折っているところがありますね。
CPU（および付随するハードウェア）または非タスクコンテキストでの検出が
前提で、そこからCPU例外ハンドラの起動に持っていくことを暗黙としていま
した。


> で，こういった案をどういうふうにフィードバックするのがよいのか
> ということについてですが…

はい。本題はこちらです。

実現というか問題解決のドメインとしては、、、

> いずれの案にせよ，タスクスタックを扱う必要がありますので，
> SILでカバーするのは難しいのではと思います．
> 非タスクコンテキストについては SIL でイケるかもしれませんけれども．

現状カーネルとSILとの関連、切り分けの問題ですが、実装主体には乱暴に
カーネルとSILとの通信手段を決めておくのも手かと思います。

> とはいえ，カーネル仕様にできるかというと難しい気もします．
> ガイドラインとかイディオムとか定石とかいう感じの文書になるの
> かなと思います．

カーネルAPI仕様の範疇か否かという観点では難しいですが、カーネルの責務
をどのように捉えるか？で変わってくるようにも思います。

しかし、現実解としては
> ガイドラインとかイディオムとか定石とかいう感じの文書になるの
> かなと思います．

というところですね。

# 藤倉さんへの返信に続く。

Shukuguchi

> こんにちは．
> 
> 動的検出の方法は，ハードウェアに頼るか，GCC の -fstack-protector のような
> ものを使うか，…いずれにしてもRTOS以外の何かにやらせたほうがよいでしょう．
> (手埋めだと網羅確保の問題もありますし)
> 
> 
> 発生時のカーネルの対応についてですが，POSIXシグナルとの類似性から，
> タスク例外処理を使いたくなる気持ちは分かります．
> しかし，タスク例外はタスクコンテキストで実行されますので，スタックが
> 溢れるかもという時に使うのは危険かもしれません．
> 
> ハードウェアの支援がある場合にはCPU例外が発生するでしょう．
> そうでない場合もソフトウェア割込みなど使って非タスクコンテキストに
> 移すほうが，より安全ではないでしょうか．標準化もしやすそうですし．
> (非タスクコンテキスト内でタスクスタックの残量を見てから
> iras_tex を呼ぶ，というパターンはアリでしょう．)
> 
> スタックの残量は，バイト数で得られれば十分ではないでしょうか．
> スタック用の配列の先頭番地/サイズとスタックポインタのアドレスは
> 現在TOPPERSが対応しているアーキテクチャなら解りますよね．
> スタック残量が僅少のときに関数を安全に呼べるかどうかは
> アーキテクチャ(もしくはABIが規定するアラインメント)依存ですが，
> 類似の問題はメモリプールでも起き得ますので，アプリ開発者の
> 解釈に委ねるとしてもよいはずです．
> 
> 
> で，こういった案をどういうふうにフィードバックするのがよいのか
> ということについてですが…
> 
> いずれの案にせよ，タスクスタックを扱う必要がありますので，
> SILでカバーするのは難しいのではと思います．
> 非タスクコンテキストについては SIL でイケるかもしれませんけれども．
> 
> とはいえ，カーネル仕様にできるかというと難しい気もします．
> ガイドラインとかイディオムとか定石とかいう感じの文書になるの
> かなと思います．
> 
> 
> 2011年4月26日22:59 SHUKUGUCHI Masahiro <shukuguchi ＠ biz.nifty.jp>:
> > 宿口です。
> >
> > 有益なアイデアだと思うのですが、意外と冷たい（？）反応でしたね。
> >
> > 静的に、タスク設計時のスタック見積りは原則だと思います。
> >
> > 動的な防護策として、ディスパッチャ、システムサービスのエントリや割込み
> > 処理の入口でのスタックチェックがあると良いと思います。これの課題（？）
> > は、処理速度とスタックオーバフローを検出した場合の振舞いの定義ですかね。
> >
> > 処理速度は、コンパイルスイッチ等でスタックチェックの有効・無効を選択
> > できれば問題は少なくなりそうですが、それだと、動的にチェックする動機が
> > 薄れます。（信用の置けないアプリケーションを搭載するような場合だと特に）
> >
> > スタックオーバフロー検出時のカーネルの振舞いは、μITRON仕様の範囲では決
> > めようが無いと思いますが、タスク例外処理の起動あたりが妥当と思います。
> > しかし、タスク例外処理の起動はマスクできますし、そもそもタスク例外処理
> > ルーチンが定義されていないと意味を成さないですね。
> >
> > また、カーネルで一意に振舞いを決めたくなりますが、カーネルに過度の機能
> > を持たせることの懸念が生じるように思います。
> >
> > # だんだんネガティブになっていく。。。
> >
> > 一方、
> > タスク観点では、タスク例外処理ルーチンでスタックオーバーフローを検出した
> > 場合に状況を知りたくなりますので、その際や、デバッグ時にはスタック状況を
> > 確認するインタフェースは有効だと思います。
> >
> > でも、CPUアーキテクチャに依存しますので、カーネルよりはSILあたりの
> > 実装になりますか・・・ スタックの情報以外にカーネル等の資源状況を調査
> > できるデバッギングパッケージなるものがあると、うれしいかもしれませんね。
> >
> > とりとめもなくすみません。
> >
> > Shukuguchi
> >
> >> 皆様
> >>
> >> 先日は多くの有用なアイデアの共有ありがとうございました。
> >>
> >> TOPPERSとしては今のところ「それはTOPPERSのサービスとして提供するものではない。」という認識に至りました。
> >> このような機能については、先日高田先生から御指摘いただいたTECSを使って実装すれば良いのかもしれませんね。
> >>
> >> 中村晋一郎
> >
> >
> >