實用的gdb 指令

最近工作上大量使用到 gdb，想說來整理一下一些常用的 gdb 使用方式，以及對應的場景；當然，這絕對不是 gdb 完整的功能介紹，只是目前我遇到比較多的使用方式而已。

檢視原始碼：
gdb 的文字介面可以顯示四種視窗：命令，原始碼，組合語言跟暫存器，與視窗相關的鍵盤組合：
Ctrl + x + a 它會分成上原始碼下命令兩個視窗
Ctrl + x + o 切換焦點所在的視窗，如果焦點視窗放在原始碼那邊，命令視窗的一些鍵會無效，例如上下鍵會變成原始碼視窗的上下瀏覽原始碼，得用 Ctrl + P (previous) 跟 Ctrl + N (next) 才能瀏覽歷史命令。
使用Ctrl + x + 1，Ctrl + x + 2 可以設定原始碼視窗分為一個或兩個，連續 Ctrl + x + 2 會依序在原始碼+組合語言、組合語言+暫存器、暫存器+組合語言三種組合中切換。
這功能可以直接看到現在執行到哪裡，特別是進到除錯熱區時，gdb 用 list 指令都會自動加10 行，要印出當下除錯的程式總有點難度，用這個可以徹底排除這個問題；不過我也覺得還沒到除錯熱區的時候，配合編輯器來看原始碼即可。

快捷鍵（這個不止是 gdb，而是大部分 shell 都適用）：
除了上述的 Ctrl + p, Ctrl + n，Ctrl + l 可以清空目前的 buffer，Ctrl +w, Ctrl + u 可以刪除命令列上一個單字或全部內容，也滿好用的。特別是 gdb 裡面 shell 下清空 buffer 的指令 clear 沒有辦法用，Ctrl + l 使用機會滿大的（前提是原始碼視窗沒開）。

中斷點設置：
有關gdb 裡面的四個點：breakpoint, watchpoint, catchpoint跟tracepoint，到現在我也只用過前兩個，99 %都是 breakpoint：
breakpoint 又分為永久跟暫時，對應 break/tbreak 後面接要中斷的位置，可以用函數名稱或者 <sourcefile>:<linenum> 兩種格式。
還可以在 breakpoint 的後面加上條件，例如 break <function> if <var> == 10，就能開始 debug 某個狀況下的執行，這在除錯有迴圈或多次呼叫函式的程式時非常好用。
start 指令，自動設置 temporary breakpoint 在主程式開始處，C/C++ 就是 main。
Watchpoint 則是用watch/rwatch 指令設置，可以監看一個變數什麼時候被動過，指令監看的目標可以是變數、記憶體位置（如 watch *0x12345678）或是幾個變數的運算也可以。
watch、rwatch、awatch 分別監看變數寫入、讀取跟讀寫。

無論是breakpoint watchpoint其實都是… breakpoint（watchpoint 有時叫 data breakpoint），可以用 info break 看到所有相關設定，還有例如它已經碰到幾遍之類。
有一個相關的技巧如下，可以計算某個函數究竟遇到幾次：

break foo
ignore <breakpoint num> 100000 //大到遠超過可能執行的數量
continue

等程式執行完就能用 info break 看到這個 breakpoint 被碰幾次。

另外 debug 時，可以利用save breakpoints <filename>把設好的breakpoint 存到檔案裡，下次可以直接source它們，save 的 breakpoint 最好只設在函數名稱上面，行數可能在debug 時變化，下次source 時就會break在不同的地方了。
我習慣上會存成 gdbinit 這樣的檔案，一進 gdb 時 source gdbinit 即可。

修改執行：
執行中可以用

set var <variable name>=<value>
set <memory location>=<value

的方式修改變數/記憶體位址內容。
例如我們發現某個條件被跳掉會導致錯誤結果，可以在 gdb 內用 set 修改變數，使它符合條件，省去重新編譯的麻煩（甚至一些狀況下，修改程式可能動到本來的邏輯，或很難使它符合條件）

跳出函數執行：
指令 finish，執行直到離開當下函數（當然遇到 breakpoint 還是會被擋）。

介面
上面的功能，有些因為最近比較常用 ddd 而非 gdb，也就沒有常用到。
另外強者我同學強強林有推一款 web-based 的 gdb gui：https://github.com/niklasb/webgdb
，據說 vscode 的 debug 功能也滿生猛的，也許找時間都來試試看。

<令人難以理解的軟體工程師生涯>心得

先前在 Facebook 上面看到這篇文章（因為怕有人沒 Facebook 權限，所以貼關鍵評論網的轉載），看了看有些心得，就打在這裡：
https://www.thenewslens.com/article/91122

話說回來，我看了關鍵評論網的引言<我們想讓你知道的是>，還是不知道它想讓我知道什麼……。

其實這篇文有點跟原文對幹的意思，身為資淺軟體工程師這麼做好像有點不識大體，不過…反正我這個小咖 blog 也沒人看，大概也沒差，而且大部分的內容，多半去看<人月神話>就有了XDD。

十倍軟體生產力是否存在？我的答案是：Yes，肯定的 Yes
這件事情不單純在軟體，各行各業都是如此，熟練的高手能得到比一般平庸的操作員數倍的生產力，軟體奇特之處在於，生產力可以高到十倍甚至更高之譜，遠超過其他行業頂尖高手和一般人之間的差距。
箇中原因，在人月神話裡面已經有解釋：軟體是人類有史以來發明過最複雜的東西，是邏輯和數學的直接表達，寫好軟體就是一次次表達腦中的虛擬結構，而頂尖的腦袋的虛擬能力，遠在一般腦袋之上；之前就有個<學長告誡>：不要去問數學高手（aka 拿了兩次數奧金牌）數學問題，他講的話你聽不懂－－他們虛疑化的層次遠超過你，你要想三步的東西他一步就講完了。
學會寫程式之後（差不多就大學吧），認識的很多很強的高手，真的是活生生體會到所謂的十倍-百倍生產力這件事，這些人現在要不是在 Google 大殺四方就是創業去了。
自己有時多少也會懷疑自己到底能不能做到那個程度，而且我相信，諸位軟體工程師的生涯中，一定也遇到過非常多10倍生產力的高手，也因此原本這篇貼文，才會獲得了如此大的迴響。

於是我們回到文中的大哉問：如果已經有了頂尖、十倍生產力的軟體工程師，那為何需要平庸工程師（就像我這種）？
軟體世界不是人多好辦事，但人少不成事。
原作者用了三個月的時間，改寫數萬行的程式為數千行漂亮的程式碼，非常厲害。
但一個 LInux 核心到現在有兩千萬行程式碼，如果像他這樣三個月估且算一萬行好了，要花 6000 個月，也就是 500 年才能寫完，這是可以接受的嗎？chrome 瀏覽器 500 萬行，firefox 一千萬行，每個都要十倍工程師孜孜不倦花好幾年手工打造嗎？還不要提現下消費者是每半年到一年要看到一次改版噢。
https://www.quora.com/What-is-the-biggest-program-lines-of-code-ever-made
這還不算上自己腦袋打結的時間，更不用提即便是天才也會有他的盲點，學的知識的它的上限，懂CPU的不一定懂網路，會演算法的可能不善於實作，懂資訊安全的可能不會硬碟……，系統長大之後會出現許多測試整合的工作，單打獨鬥鐵定有一個上限存在。
大型軟體本來就要綜合眾人之力，這又回到本來的問題：集合眾人就要溝通問題本質的數學邏輯，然後發生誤解跟整合問題，就算團隊全部都是10倍生產力工程師也無可倖免，以前總以為一流的軟體公司，像什麼 Google, Amazon 什麼的，裡面的程式一定都是藝術品等級，後來問問任職的同學，才發現根本不是這回事，有點年紀的大公司，軟體總是變成一團屎，還聽說過有幾個檔案變成 magic code ，根本沒人敢動的。

在跟強者我同學一哥聊天時，就有說到：「公司花錢請你來是要解決問題，不是把公司的東西變藝術品」、「每家公司都有鳥事，所以沒方向的話就選薪水高的」聽起來很世儈，但現實如此。

其實這幾年來，一直覺得台灣軟體最大的問題，並不是我們沒有夠多的10倍生產力軟體工程師，10倍軟體工程師本身就是一個異數，也許培養一群人裡，比例也就這麼多；更何況，過度看重十倍軟體工程師，顯然把世界想得太簡單，以為不管什麼問題，只要派出一位10倍軟體工程師都能迎刃而解，但很多問題卻不是如此。
我覺得我們最缺的，是培育出許多平庸的軟體工程師之後，如何拉一位 10倍軟體工程師，把大家組織成部隊來打群架（順帶一提，所謂的平庸工程師, 是指：給定一個嚴謹的規格，可以四平八穩完成開發，不要寫出會 buffer overflow 之類的低級錯誤，足矣。），我們很喜歡強調個人能力不足，但現在這個時代，就是要靠打群架才能打勝仗，如何把 10 位平庸的工程師組織起來，搭配一位 10 倍生產力的工程師，變成 50 倍生產力的團隊？只靠單打獨鬥，我們要如何挑戰百萬行甚至千萬行的系統？
也許哪天我們會看到：原本千萬行的程式，大家一起重寫的只剩下百萬行，功能不變，效能更好，而且架構儼然。前幾天完成 Alpha 版之後，大家不禁開瓶慶祝，笑聲充斥整個辦公室。

這大概才是台灣要追求的方向。

話又說回來，其實寫程式就只是寫程式，就算不寫程式跑去教書，腦袋還是可以想程式邏輯；上班寫無聊的程式，下班還是可以繼續學有趣的東西；就算當管理職不寫程式，把軟體架構切好，交給下面的團隊幫忙開發，對專案就沒有任何助益？誰說只有寫程式，還要寫得快又寫得漂亮才能貢獻社會？
理論上我們可以用寫程式數倍的時間，一行一行驗證我們的程式碼有沒有問題，把程式改到完全不會出錯，但世界不鳥這些，<不吃飯不睡覺，打起精神數鈔票>比較重要，程式當掉資料飛了，跟客戶土下座就好，反正沒有一次土下座解決不了的問題，如果有，就兩次。

寫程式其實沒有這麼偉大。

我們持續寫下去，只是因為寫程式很快樂，解決問題很快樂，重新打造輪子很快樂（等等…），覺得自己又變厲害了很快樂，完成大系統裡的小螺絲，很快樂
每位程式設計師，其實都是無可救藥的樂觀主義者。

Coursera Introduction to Logic

前些日子開始修了 coursera 上 stanford 大學開的 Introduction to Logic，修完而且有學到東西，其實個人習慣上滿常亂加一些 coursera 上的課程，有些聽一聽覺得無聊就沒聽完，沒聽完的就不會在這裡推薦就是。

下面是基本資訊：
課程名稱：Introduction to Logic
開課學校：Stanford University
授課教授：Michael Genesereth
開課時間：10 周
教學方式：靜態講義
通過方式：每週完成指定的作業，下面會詳述作業內容。

課程內容涵蓋基礎邏輯的概念，符號介紹，邏輯證明跟歸納證明，沒有到太複雜的內容，如果在台灣的大學有修邏輯的話，應該也是差不多的內容，例如通識很熱門的<邏輯丙>，應該內容也差不多。
不像其他課程是教授親自上陣講課，這門課上課的方式是看靜態文字講義（似乎有簡體中文不過我是看英文的），講義看過之後會自動記錄看過，相對來說看靜態文字比看教授講解還要無聊一些，而且有點吃英文能力。
課程內容很大一塊是放在 fitch system，並且證明也都是用 fitch system 來證明，每周作業會出約莫 5 到 10 題的題目，有些是選擇題，選到正確的選項即可；有些則是證明題，要證出所要的結果；有幾週會加一些邏輯遊戲跟參考影片，例如邏輯踩地雷，或者看教授演示一個邏輯表達系統。
證明題使用的是一個 javascript 寫的證明系統，可以用滑鼠選擇敘述，還有要使用的運算來完成證明，一開始有一點難上手，不過熟練之後就會覺得設計真的非常厲害，For all 跟 Exist 的符號代換都會自動完成，點一點就發證明完成了。唯一卡比較大的是在第八週的歸納法，久違地動用紙筆在紙上釐清議義範例證明的思路，想通之後在系統上重現就清楚多了。

學完之後真心覺得有學到東西，我從來沒想過原來連 (p => q) => (~q => ~p), (p => q) => (~p | q) , (p | ~p) 這樣基礎的邏輯也可以證明，但是千真萬確，證過一次才知道這真的可以用邏輯推出來，所以以前說的那些：前題錯就可以推出任何東西，「如果月亮是起司做的，那麼月亮可以吃」都是真的。
其他要注意的事情：寫作業的系統不知道為什麼，用 chrome 開的話會有些問題，用 firefox 來操作就沒問題。
另外，我誠心建議大家睡前不要讀邏輯，讀邏輯當然要沐浴更衣正襟危坐有一次念完之後睡覺，結果在夢裡想歸納證明………，醒來累得半死。