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

[Meika Sugimoto]

ナカムラ様

杉本です。

結論から申しますと、スタックの見積もりは
設計時に、静的に行う必要があります。
また、その見積もりはツールを使うべきでしょう。

スタックの使用量算出は、タスクの
関数呼び出しツリーを
追って行き、その中で最も多くスタックが伸長するパスを
探索して行います。

この手順を手で行うのは大変ですし、もしタスクに十分なスタックが
なければサービスコールを読んだ
時点で暴走する可能性があります。


ただ残念なことに、GNUコンパイラではそういったツールがないと
認識しています。
なので私も困っています。

binutilsを駆使したらツールを作れるのかも知れませんが、
調べたことはありません。


商用コンパイラにはたいてい付属しているので、簡単にスタック使用量が分かります。
ただしアセンブラで記述されている関数や、関数ポインタでの
呼び出しは算出できません。
前者に関してはターゲット依存部にドキュメントとして
記すことで対応できそうです。

以上、よろしくお願いします。

Ｍeika Sugimoto

On 2011/04/18, at 7:00, Shinichiro Nakamura <shinta.main.jp ＠ gmail.com> wrote:

> 素朴な疑問なのですが、皆様はタスクスタックの状況確認をどのように行なっていらっしゃいますでしょうか？
> 
> ふと疑問に思い調べてみたところ、標準のシステムコールではできないとの判断に至りました。
> これは、非依存部にはスタックの先頭アドレスとサイズのみが保存され、依存部にスタックポインタをおくためです。
> 
> とにかくOSの機能として実現してみたかったので、いい加減な名前を付けて非依存部のスタック先頭アドレスと依存部のスタックポインタを使って取得する機能を作ってみたところ、意外に具合が良いです。
> http://shinta-main-jp.blogspot.com/2011/04/toppersquick-and-dirty.html
> 
> 確かに「見積り」と称してて手計算するというのもアリかもしれませんが、私にとっては魅力的ではありません。
> 人手で抽出しようとすると、漏れや思い込みがありますし、時間がかかるからです。
> 商用ツールにその領域を譲っているという見方もできますが、それはTOPPERS自身の魅力ではなくなってしまいます。
> 
> そこで、タスクスタックの状況を確認するためのシステムコール実現を１ユーザの立場から提案したいと考えです。
> 
> これにより、
> 　「スタックの余裕度をある程度判断できる」
> 　「誤った実装によるRAM消費などを未然に確かめることができる」
> などの効果が期待できます。
> 
> また、上記効果によってTOPPERSを採用するシステムの安定性が結果的に向上し、更なるユーザを獲得できるのではと考えております。
> 
> 私の現状の実装は、依存部にあるタスクコンテキストブロックp_tcb->tskctxbを参照していますので極めて不適切な状態ですが、何らかの方法で同様の機能をカーネルに入れることは可能ではないでしょうか？
> 
> TOPPERSは触ってみると楽しい道具です。
> 沢山のOSが組み込み市場に流れてくる中で開発者も流動的になっていますから、
> システムの安定性や作りやすさ、導入時の利便性を兼ね備えた機能がTOPPERSに加わり、
> 厳しい組み込みOS市場で多くの開発者とユーザを獲得して頂ければ個人的には嬉しい限りです。
> 
> 皆様とご意見やナレッジなどを共有させて頂ければ幸いです。
> 
> 中村晋一郎
> 
> P.S.
> これは本当に余計な話ですが、シェルなんかも標準で入っていると嬉しいです。
> （シェルのないOSって便利なデバッグ用環境をどう構築して良いかわかりませんよね。）
> http://shinta-main-jp.blogspot.com/2011/03/natural-tiny-shell-nt-shell.html
> http://shinta-main-jp.blogspot.com/2011/03/natural-tiny-shellnt.html

-------------- next part --------------
HTMLの添付ファイルを保管しました...
URL: <http://www.toppers.jp/pipermail/users/attachments/20110418/8e0fc8b1/attachment.html>