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

[T.Fujikura]

藤倉です
　スタックOverflowと戻り番地破壊は分けて考えた方が良いのでは無いかと思
う。GCCは戻り番地破壊? ハードに依存はOverflow?

(2011/04/29 12:25), Masaki Muranaka wrote:
> こんにちは．
> 
> 動的検出の方法は，ハードウェアに頼るか，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を使って実装すれば良いのかもしれませんね。
>>>
>>> 中村晋一郎
>>
>>
>>
> 
> 


-- 
//T.Fujikura