ビルドの流れをおさらい
ソースファイル(.cや.h)→コンパイル実行→オブジェクトファイル(.o)、
ライブラリやモジュール(.aや.ld)→リンク実行→実行可能ファイル(.motや.run)
※拡張子は適当
デバッグ時の心構え
・プログラムを詳細に理解する（フローチャートを用意しておくといい）
・特に非効率なのはプログラムコードを理解しない状態で
修正してみてはコンパイル実行の繰り返し
Q1:ビルド実行時、何らかのシンボルが定義されていない系のエラー
→どこの段階でのエラーかをまずは確認する
☆コンパイル段階でのエラーの場合
・タイプミスないか（セミコロン抜け、文字コード、タブ、全角など）
・定義されてないシンボルを参照していないか
・ヘッダーファイルのインクルードが正しくできてるか
・実際のエラーを示す行と問題の行が一致しているとは限らない
☆リンク段階でのエラーの場合
・必要なライブラリやモジュールをリンクできているか
・古いプリコンパイル済みのヘッダーファイルを参照していないか、
疑わしければリビルド（再コンパイル）する
Q2:ビルド実行時、ヘッダーファイルが見つからないエラー
・環境変数INCLUDEは適切に設定できているか
・コンパイルオプションの指定は正しいか
・IDE利用中であれば、IDEのプロジェクトの設定は正しいか
Q3:処理速度が要求を満たしていないとき
・コンパイラの最適化機能で速度優先にする
・配列のループ格納処理をポインタにする
・関数をマクロにできないか検討する
・Cからアセンブラにする（インラインアセンブラもしくはソースファイルごとアセンブラ）
・メモリ定義をレジスタ（register)にする。現場では見たことない
・サイズの小さなデータ型を使う
・シフトを使って計算を速く行う
・短絡評価（演算子の左側の数を評価した段階で式全体の値が
定まらない時のみ右側を評価）を使う
例：if(func()>3 || x>3) ではなく 、
if(x>3 || func()>3) こう書いておけば、
x>3の時はfuncが呼ばれなくて無駄な処理時間を省ける。
Q4:どこかでリセットが掛かっているが原因不明のとき
・リセット要因レジスタに条件付きwriteブレークを張り、リセット要因を特定する
☆ハードウェアリセットの場合
・ウォッチドッグがリセットしてるかも（外部、内部どちらかも判別しておく）
・電源ICの仕様を確認する
☆ソフトウェアリセットの場合
・Resetで飛んでくる処理の先頭にブレークを張って、
止まったときのコールスタック（関数の呼び出し履歴）を確認すると分かることもある
・二分法などを用いてリセット発生させてる処理を特定する
・無限ループに入る→ウォッチドッグがリセットのパターンはよくある
・想定と全然違うところで問題発生してる場合はスタックオーバーフローも疑う
Q5:デバッガ操作前に事前に知っておきたいこと
・ステップ実行、ステップオーバー実行の違い
・ソフトウェアブレークとハードウェアブレークの違い
・コールスタックの見方
・レジスタの見方
・pc(プログラムカウンタ)で現在番地を操作する
Q6:デバッガ接続時は問題ないが、デバッガ未接続時のみ問題が発生する
・デバッガではRAMなどのメモリを事前にクリアしており、問題ない挙動になることがある。
・デバッガではウォッチドッグが無効になっており、問題発生しないことも