> スタックの情報以外にカーネル等の資源状況を調査
> できるデバッギングパッケージなるものがあると、うれしいかもしれませんね。
私が皆さんにお伝えしたかったのはまさにこの点なのかもしれません。
だったらそう言えという話になるかもしれませんが、具体的な例がないと難しいと思いましたので。
私の提案は厳密なスタック見積もりというよりも、「この程度使っているなぁ。」程度でも
「見れないよりは良いよね？」という趣旨のものでした。
例えば、Doxygenでコールグラフを作成して、一番深くてスタックに大量に変数を積んでいる所で、
そのシステムコールを呼んでみようといった具合。
あるいは全てのパスで呼べるようにしておいても良いですが。
スタックサイズギリギリのところで使うのは論外として、余裕があるところで見るのであれば、
何割くらいの余裕があって、コンテキストの保存にこのくらい使って・・・程度でも良いのでは？という。
（たまにありますよね。「あ、このデータRAMに載ってた。あぁ、こりゃだめだ・・・。」みたいなこと。）
→ちょっと無理矢理なシナリオですが。
TOPPERSは条件に従い無償で使用できる上、カーネルの実績としては申し分ないものがあります。
近年、組み込みOSを取り巻く状況も目まぐるしく変化する中で、「いきなり使いやすいパッケージ」が
オープンソースであるともっと嬉しいなぁなんて考えているところです。
今回TOPPERSを始めて本格的に使ってみたフィードバックをTOPPERSの皆様にお伝えする事が
今後のTOPPERSの発展につながるのではと思い至りお伝えした次第でした。
（私自身、他のRTOSを使った開発の経験がありますし、転向組のティピカルな意見では？なんて思ったり。）
カーネル開発者にとってはユーザの様々な意見に、もうウンザリという事もあるかも知れません。
ですが、ユーザが気軽に意見を言える雰囲気というのもコミュニティが成長するか衰退するかを左右するような気もしています。
宿口様を始め、みなさんが真摯に議論して下さり大変感謝しております。
中村 晋一郎
2011年4月29日17:00 Masaki Muranaka
<monamour@monaka.org>:
こんにちは．
分けるとすると，スタックの中が壊されるか，スタックを超えて壊されるか．
でしょうか．(スタックの中は戻り番地だけというわけではありませんし．)
-fstack-protector の"ようなもの"とぼかしたのは，ご指摘のとおり
スタックの外の破壊には気づけないからです．オーバフローへのGCCとしての
取り組みとして -fmudflap があったりします．いずれも，TOPPERS でどれだけ
使えるかは未知数です．直感ですが．大規模なhackが必要でしょう．
(ここでは，RTOSではなくコンパイラで対応する実例があることが，重要です．)
一方，ハードならオーバフローが検出できるかというと，保護ハードウェアの
粒度より小さなメモリ領域のアクセス制御はできませんし．大抵は保護区画を
作る資源に限りがあります．スタック内部の破壊にハードが無力かというと
必ずしもそうでもないですよね．アラインを間違えた書込みに対して例外を
出すアーキテクチャも，割とあります．
こんな感じで分けていくと，個々のシステムへの理解は深まりますが，
仕様(もしくはガイドライン)としては発散しそうです．「ヤバいことが
起きたときに，収束させるにはどのような設計がありうるか」という
辺りまでなら，共有できる知識として纏めることも不可能ではないかなと
思っています．
2011年4月29日12:59 T.Fujikura <fujikura@ymail.plala.or.jp>:
> 藤倉です
> スタック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
>
>