關於Lab11的de-bug環境

[陳伯綸]

請問有人有實作與Lab-9類似的dug環境嗎？

我將中斷點設在first() //執行fork的function

還有main裡面第一個while迴圈判斷式switch (tasks[current_task][2 + 7])

還有選擇判斷式 while (TASK_READY != tasks[current_task = (current_task+1 >= task_count ? 0 : current_task+1)][-1]);

然後displays tasks

tasks = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}

執行結果照理說會跑進去first()裡面call fork()

然後原本的tasks最後會是這樣的結果

tasks = {0x95cc, 0x7fcc, 0xb474, 0xc5cc, 0xd5cc, 0x0, 0x0, 0x0, 0x0, 0x0}

可是在執行de-bug的有時候會有

tasks = {0x95cc, 0x7fcc, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}

才執行第一個fork function   if (!fork()) pathserver();

整個環境就卡著了//必須使用ctrl+c

重新取回控制權後在執行,不論是run或next都一樣會在度卡住

不曉得是否是我自己的問題？

還是有人也碰到類似的問題？

[Jim Huang]

hi 伯綸,

因為目前 kernel 進行 context switch 時，會破壞 stack 結構，以至於讓 GDB 無從追蹤起，而當你完成一次
task switch 時，又恰好看到上一次的狀態。

我會建議你改用 watch，直接看 task queue/list 的內容，這樣會比較單純。

Regards,
-jserv

> --
> 您已訂閱「Google 網上論壇」的「embedded2013」群組，因此我們特別傳送這封郵件通知您。
> 如要取消訂閱這個群組並停止接收來自這個群組的郵件，請傳送電子郵件到 embedded2013...@googlegroups.com。
> 如需更多選項，請前往：https://groups.google.com/groups/opt_out。
>
>

[陳伯綸]

我想弱弱的再補問一個問題

現在我們的重點是放在因為它沒有明確的task struct,所以這個部份是我們得賦予的？

以上

[Jim Huang]

hi 伯綸,

你可以設計更好的 TCB，讓 priority based scheduling 得以更好的呈現。

現在許多 hack，如 [2 + 0] (0 means value of r0, return value of syscall) 與
[2 + 7] (7 means r7, syscall number)
相當不優雅，多少也讓同學誤解。

Thanks,
-jserv

[陳伯綸]

thanks，感謝您指出了個方向

因為我花了很長的時間在做GDB的trace試圖了解它們背後的涵義，但是總是覺得觀念上無法與實際的trace結果吻合

我想這也許是C到用實方恨少