軟體學徒forever

工程人員最怕遇到隨機出現的bug，尤其是IC廠的軟體工程師，既要懷疑自己的軟體流程，又要同時有能力區分是否為IC bug（因為硬體出錯的機率相較於PC平台來說高出很多...）。最近面對一個bug，竟然花了兩週的時間才整個釐清並解決...事後自己反省，覺得有很多值得改善的地方。 問題是這樣的：當系統開機時，發現我負責的模組在約40s~50s左右會隨機的timeout，或遭遇奇怪的錯誤情況，最後讓整個系統當掉。 由於單獨模組都已經通過了壓力測試，所以我第一個反應就是先檢查硬體。觀察了外部訊號，但沒有發現任何異樣。接著觀察相關registers，發現掛掉的時候讀到了非常奇怪的數值。由於該數值是controller直接從DRAM獲得，所以有可能是DRAM不穩嗎？不對，因為幾乎每次都掛在我這邊，如果是DRAM不穩，那應該到處都會著火。 那麼，是bus上出問題嗎？一想到這，心就涼了半截...但還是硬著頭皮觀察IC內部bus訊號（AHB signal，嗯，你不用在乎這是什麼 XD）結果，真的發現在發生問題時，bus signal非常的異常。這下designer緊張了，這可能會影響到是否已下單的wafer是否全部泡湯的問題。於是，一堆人開始出主意：有沒有試過ooo、有沒有試過xxx、＃＄％︿＆＊＊（！... 由於出意見的人都是有掛頭銜的，所以往往都要先確認他們的意見是否成立。嗯，這是我犯的第一個大錯： 花了太多時間應付長官的要求，而非處理事情的本質。 由於長官並不那麼清楚整個始末，但又因為可能是大問題，所以自然吸引人們出意見。但是我應該在當時就說明清楚，而不是默默承受無釐頭的要求（ 懂得何時說"No"就跟懂得何時說"Yes"一樣重要 ）。嗯...總之，這樣一個禮拜就過去了，客戶也開始著急了起來，質疑什麼問題需要一週還沒任何結論。 接著，長官們沒想法後，總算可以開始自己的實驗，很快地發現某個模組只要一發生錯誤，我的部份再過幾秒後就出問題。所以將重點移到該模組。詢問該模組負責人相關流程後，對於為何會出錯也很納悶，畢竟...嗯，他自己單獨跑也是經過了好幾天的測試...好了，所以問題是出在兩者間的交互作用導致bus出問題嗎？於是我們開始了這兩個模組的co-sim, FPGA CVT...這邊則是我的第二個錯誤： ...

一個多月沒有寫 blog 了...並不是沒有東西想寫，而是剛好換了新工作，並且接了幾個有時程壓力的任務，所以每天都累得跟狗一樣... :P Anyway，趁今天早點下班，將一個工作上遇到的連結問題紀錄一下，或許對某些朋友剛好有幫助。問題是這樣的，在某個使用 MIPS GNU toolchain 的環境中，原本一份可以順利編譯的 code ，今天加了一點  code 後，突然出現了連結錯誤： relocation truncated to fit: R_MIPS_GPREL16 against `no symbol' 大家似乎都第一次遇到這個錯誤，google 一陣子找不太到直接解法，但是隱約看到有人提到跟 small data section、register GP 有關，記得在 See MIPS Run 中有描述過類似的句子，翻開教科書(chapter 2)，果然提到 GP 可能會被利用來作為快速的 addressing 方式，但由於要在一個指令作完 addressing ，所以只能用到一個 32 bits 指令的 16 bits，所以如果是以 GP-relative relative addressing 方式來作 relocation ，就必須注意資料必須在 GP 的前後 32KB 的範圍。也就是說，我們有兩種解法： 檢查 toolchain 將哪些 sections 的存取或指令用了 GP-relative addressing，然後改寫 linker script 將這些 sections 與 script 中的 _gp 排近一點(在 reset.S 之類的地方通常會拿 _gp 當作 GP 的值)。 利用編譯選項 -G0，使其不要產生 small data section，而這看起來似乎就是靜態連結時的唯一一種會用的 GP-relative addressing 的 section 。  我們採用方法1，因為方法2似乎有人有遇過不少問題，為了避免又撞到這類 link error 問題，先用安全點的作法。:-)

In the previous post , I mentioned two great books about debugging. In this article, I want to share a real case which is solved by using some tricks. Last week, one of my colleague came to me and asked me a question: There is a Python script running. But can not use "kill process_pid" to kill it. Only "kill -9 process_id" works. Why? My first guess is that the script installing a signal handler and not exit. My colleague promised it did exit. OK, let's check. First step, we observe the process's status by using ps: shit 17392  99.7   0.2 244216 23300 ?         Rl     Aug10 9149:48 python /shit . py /shit . config Hey, it is running and occupying almost CPU time. This means it may trap into some infinite loop. But there is no loop in the handler. Hmmm, some bug hidden in lower level? How to identify this? We use gdb to attach the process and see where it is: (gdb) attach 17392 (gdb) where #0  adns_forallqu...

Recently I read two fantastic books about debugging. I think they might be useful to others, especially for junior programmers :-) The first one is " The Developer's Guide to Debugging ". This book is very pragmatic and thin. It is only 2xx pages. But its length doesn't mean its content is shallow. In the contrary, it is very dense. It covers wide range about debugging, including debugger usage(basic and advanced tricks), memory leak and corrupt detection, profiling(memory and CPU), parallel issues, environment issues, linking issues, how to write debuggable code, static checking and how to integrate all of them with system thinking!! I have this book years ago but realize its value after programming several years. My bad. The second one is " Why Programs Fail ". The author is know for his work for creating DDD . This book shows the "science" perspective  of debugging. It tackles an advanced issue: automatic debugging. If you want to know t...