gdb: 維持永久的 watchpoint

若想觀察特定變數的變化, watchpoint 比 breakpoint 易於使用。但 watchpoint 有個小問題, 一但離開 scope 後, gdb 會自動刪掉 watchpoint。

若該變數是 member field, 就無法持續追踪不同 method 怎麼讀取或寫入它的值。這篇提供一個小技巧, 取用目標變數的指標, 再觀察指標取值的變數, 藉此讓 gdb 認定它不是區域變數, 借用該文的例子如下:

(gdb) p &var1
$1 = (int *) 0x41523c0
(gdb) watch *(int *)0x41523c0
Hardware watchpoint 1: *(int *)0x41523c0

若真的是區域變數的話, 可用 commands 定義簡短的指令, 之後進入函式時, 自動加回 watchpoint, 借用該文提供的例子:

(gdb) break func
(gdb) commands
>   watch var
>   continue
> end

commands 看來很方便, 還有許多適合應用的情境, 像是追踪網路連線輸出關鍵資訊, 可避免手動操作太久造成 timeout。

2012-02-04 更新

gdb 7.4+ 支援 watch -l, 就不用自己取位置再設 watchpoint 解套。在 7.4 之前想用這功能, 可使用 Scott 寫的 gdb-watch-location.py。用法是

$ wget https://raw.github.com/scottt/scottt-gdb/master/gdb-watch-location.py
$ gdb -x gdb-watch-location.py PROG

在 gdb 裡會新增幾個指令: watch-l、rwatch-l、awatch-l 對應到 watch -l、rwatch -l、awatch -l。

讀懂函式庫的 man page

初學 Linux 時, 覺得 man page 真不是寫給一般人看的, 到像是寫給已經懂的人備忘用的。即使現在已比較習慣讀 man page 了, 還是這麼覺得。

以前只知道 man function 看要引入什麼 header, 了解函式的參數、傳回值。最近才明白裡面的其它資訊。

背景知識可以搜尋 "how to read man page" 或看 Wikipedia 介紹得知。這裡只針對使用函式庫講基礎知識。另外這裡有顯示彩色 man page 的設定。

以 man 3 sqrt 為例:

SQRT(3)                                          Linux Programmer's Manual                                         SQRT(3)

NAME
       sqrt, sqrtf, sqrtl - square root function

SYNOPSIS
       #include <math.h>

       double sqrt(double x);
       float sqrtf(float x);
       long double sqrtl(long double x);

       Link with -lm.

   Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

       sqrtf(), sqrtl():
           _BSD_SOURCE || _SVID_SOURCE || _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE || _POSIX_C_SOURCE >= 200112L;
           or cc -std=c99

• #include 表示需要的 header
• 下面有函式的 signature
• Link with -lm 表示使用 gcc 編譯時要加 -lm, ld 才會找到 libm.so。詳細的運作過程見《ld, ld.so 和 ldconfig 的行為》
• Feature Test Macro 是 UNIX 跨平台用的一套規範, 見 man feature_test_macros 了解 feature test macro 的作用, 以及 glibc 認得的類型。feature test macro 要定義在檔案的一開頭才行, 或用 gcc -D 定義。

關於 feature test macro, 這裡指出要定義 _BSD_SOURCE、...、_XOPEN_SOURCE 等, 才能使用 sqrtf() 和 sqrtl() (math.h 才會引入它們的宣告}}}。反之, sqrt() 有跨所有平台, 可直接使用。

這裡和這裡有相關說明, 解釋 -std=c99、-std=gnu99 的效果, 會定義不同的 feature test macro。若沒有考慮可攜性的話, 用 c99 編不過時改用 gnu99 可編過, 不用擔心會有什麼副作用。

所以, 要使用特定函式時, 要先看 man FUNCTION 了解需要定義的 feature test macro, 讓 compiler 可以編過。再來從 man FUNCTION 得知 static linking 需要的參數。

要檢查目前程式定義了那些 feature test macro, 可以用:

gcc -E -dD MYPROG.c

除查看 feature test macro 外, 用來查引入的常數也很方便, 比方說忘了 stdin 的 file number 的常數, 引入 unistd.h 後, 用 gcc 展開看一看, 就會找到#define STDIN_FILENO 0

使用 RTLD_NEXT 實作 wrapper

先貼程式:

// RLTD_NEXT is only supported in _GNU_SOURCE.
#define _GNU_SOURCE

#include <stdio.h>
#include <dlfcn.h>

void *malloc(size_t size) {
    void* (*m)(size_t);
    // 「標準」取得 function pointer 的寫法. 見 TLPI 42.1.2 p863 的說明
    *(void**)(&m) = dlsym(RTLD_NEXT, "malloc");
    printf("local malloc\n");
    return m(size);
}

int main(void) {
    int *t = malloc(sizeof(int));
    *t = 3;
    printf("%d\n", *t);
    return 0;
}

編譯和執行結果:

$ gcc m.c -ldl -o m
$ nm m | grep malloc
0000000000400604 T malloc
$ ./m
local malloc
3

若去掉 malloc(), 加上 #include stdlib.h, 用 nm 看則是:

$ nm m | grep malloc
                 U malloc@@GLIBC_2.2.5

表示在 m 裡面沒有定義 malloc, 它存在 glibc 裡。malloc 後面的 "@@GLIBC_2.2.5" 是 version tag。當 shared library 裡有多個版本 malloc 時, 可用 version tag 來區別要用的是那一個 malloc, 詳情見 TLPI 42.3.2。

這裡的關鍵是 glibc 定義了擴充功能 — 假的 library handle: RTLD_DEFAULT 和 RTLD_NEXT。用前者取函式 (變數) 就和原本 ld.so 找 symbol 的方式一樣; 而後者則會找「下一個」, 這是針對實作 wrapper 的需求而定的。

由於是 glibc 的擴充, 編譯時要在開頭加上 #define _GNU_SOURCE 或在命令列加 -D_GNU_SOURCE, dlfcn.h 才會載入 RTLD_NEXT。關於 _GNU_SOURCE 的說明, 見《讀懂函式庫的 man page》。

ld, ld.so 和 ldconfig 的行為

TLPI ch41 相當值得一看, 從開發者使用 library 的角度說明 library 的生成、靜態連結、動態連結 (載入) 的行為, 內容不多不少, 正好就是我想知道的, 省了看 linker、loader 的時間。

shared library 的名詞介紹

• soname: 記錄在 shared library header 裡的名稱, 格式為 libX.so.MAJOR。要有同名檔案, 供之後程式載入 shared library 時使用
• real name: shared library 的檔名, 格式為 libX.so.MAJOR.MINOR.NUMBER
• linker name: 對 library X 來說, 就是 libX.so, 一般會是 symbolic link 指向最新的 major shared library

以 libjpeg 為例, 對應如下:

libjpeg.so -> libjpeg.so.62.0.0     # linker name
libjpeg.so.62 -> libjpeg.so.62.0.0  # soname
libjpeg.so.62.0.0                   # real name

這是我在 Ubuntu 裝好 package 後的樣子, 照理說 libjpeg.so 指向 libjpeg.so.62 應該會更彈性。

讀出 soname:

$ readelf -d libjpeg.so | grep SONAME
 0x000000000000000e (SONAME)             Library soname: [libjpeg.so.62]

static 和 dynamic linker

• ld (ld.bfd) 是 static linker。Google 開發的 gold 是取代 ld.bfd 的 static linker。用 gcc 連結 shared library 或 executable 時就是呼叫 ld, 並將需要的參數傳給它。不論連結的是 static library 或 shared library, 都是 static linking。
• ld 在連結 shared library 或 executable 時, 會將需要的 shared library 的 soname 寫入結果檔裡。注意, 只有 soname 而已, 沒有完整路徑。
• ld-VERSION.so 是 dynamic (runtime) linker, 執行程式時, 由 runtime linker 載入 executable 開始。若 OS 用的 glibc 版本為 2.13, 就叫 ld-2.13.so。用 ldd 看所有執行檔, 都會找到它 (某個 symbolic link 連到 ld-2.13.so)。

以連結 libm.so 為例, 執行 gcc -lm prog.c -o prog 中間的部份行為如下:

1. gcc 透過 -lm 的指示告知 ld 要連結 libm.so
2. ld 會找到某處的 libm.so 指向 /lib/x86_64-linux-gnu/libm.so.6, 確認要用到的 symbol 都有, 沒有 link error
3. ld 從 libm.so.6 的 header 讀出 soname "libm.so.6", 寫入 "libm.so.6" 到 prog 的 header。

執行 prog 時, ld-2.13.so 會從 prog 讀出 "libm.so.6", 再到預設的路徑上找檔名 "libm.so.6"。注意, static linking 時需要 libm.so, 但之後執行 prog 時用不到它, 因為記錄的 soname 為 "libm.so.6"。

關於 static linking 找檔名的順序, 可用 strace 觀察:

$ strace -e open,execve -f -o gcc.trace gcc -lm prog.c -o prog

在 gcc.trace 裡可看出一二。

ps.

• 使用 execve 的目的是知道 child process 是那一個程式, 目標是看 ld 開敋的檔案
• 可由 man 2 exec<TAB> 得知 system call 使用的 exec 函式為 execve。

ldconfig

執行 ldconfig 後, 它做的事如下:

1. 讀出 /lib, /usr/lib, /etc/ld.so.conf 內的路徑之下的 shared library (ldconfig 會略過 symbolic link), 將結果寫入 /etc/ld.so.cache。之後 ld-2.13.so 會用 ld.so.cache 的記錄來找 shared library。
2. ldconfig 會自動產生 symbolic link "libX.so.MAJOR" 指向最新版本的 shared library。例如 /lib/libfoo.so.2.0.1 的 soname 是 libbar.so.2, 執行 ldconfig 後, 它會產生 /lib/libbar.so.2 指向 /lib/libfoo.so.2.0.1。

之前困擾我許久的事就是第二步, 而 man ldconfig 裡沒提到這點。

結論是別隨便手動更新 soname 的檔案, 執行 ldconfig 後可能會出問題。裝套件後, 系統工具會自動跑 ldconfig 更新目錄, 可能會蓋掉自己手動更新的同檔名檔案。另外 ldconfig 沒有管 linker name, 若是自己編的 shared library, 要自己產生。

其它

若想連到舊的 major 版本 shared library, 得在 gcc 參數指定舊版檔名。還有可用 rpath 的參數寫入搜尋 shared library 的路徑到 shared library 或 executable 裡。關於這些細節, 還有 static linker 以及 dynamic linker 尋找 shared library 的完整順序, TLPI ch41 講得相當清楚。ch42 描述 dlopen, 之後再來翻翻。

2015-09-05 更新

加上 Scott 補充關於 ld-VERSION.so 和相關工具的說明:

fcamel: ld-2.21.so, ldd, ldconfig 屬於 glibc 是什麼意思啊? 我以為 glibc 是 standard C + POSIX lib

Scott: Linux 下動態連結器是 C Library 的一部分，例如 Android 不用 GLIBC 所以其 Dynamic Linker (/system/bin/linker64) 是 Google 自己寫出來、自己維護的 https://github.com/android/platform_bionic/blob/master/linker/Android.mk。

這個知識可用來解釋 Android 動態連結器有許多「特異功能」，例如有註冊 SIGSEGV handler，所以 native code 記憶體存取錯誤會有 backtrace 等。 https://github.com/android/platform_bionic/blob/master/linker/debugger.cpp

至於動態連結器為何是 C Library 的一部分，從「實作 C library 的人」的角度看：凡不是 Kernel，但又是系統「執行期間」需要的低階 Library，就擺在 C Library 內了。

ldd 與 ldconfig 是 GLIBC 作者寫出 ld-2.21.so 動態連結器時「順便」寫的工具，是隨 GLIBC 一起安裝的。系統不用 GLIBC 的話，可能沒有 ldd 與 ldconfig。

C99 好用的語法

之前只有用到 C99 的 loop initial declarations (在 for 的初始化部份宣告變數), 看 Scott 提到才知道有其它好東西, 順便來掃一下 C99 的功能

stdbool.h

定義 bool、true、false, 實際上是將 bool 對應到 C99 定義 _Bool

stdint.h

定義了整數範圍、int16_t、int32_t、int64_t 等型別, 再也不用查 short/int/long 等在 32/64 bit OS 上的大小為多少。

designated initializers

可攜又易讀的初始化 (ref.)

// array
int widths[] = { [0 ... 9] = 1, [10 ... 99] = 2, [100] = 3 };
// struct
struct point { int x, y; };
struct point p = { .y = yvalue, .x = xvalue };

像要用建表實作 isspace() 的話, 這樣寫超清楚的:

bool myisspace(int ch) {
    static bool whitespace[256] = {
        [' '] = true, ['\t'] = true, ['\f'] = true,
        ['\n'] = true, ['\r'] = true
    };

    if (ch < 0 || ch >= 256)
        return false;
    return whitespace[ch];
}

其它

像 snprintf、inline、variable-length array (例如 int array[n]) 也很實用。

signal 小知識

看 TLPI 長知識。

signal 設定和 fork

fork 後會繼承 signal 全部設定, 而 exec 後會保留 ignore 的設定, 但因為 address space 不同, 會將有設過的 signal handler 改回 default handler(見 man 7 signal)。

先送 SIGTERM 再送 SIGKILL 砍程式

若程式有照標準寫, 可能會有 SIGTERM 的 handler, 在收到這 signal 時做些清理動作 (砍暫存檔、釋放資源等), 再自我了結。而 SIGKILL 就直接掛了。所以, 先給人家一個機會掛得優雅一些, 若對方拒絕的話, 再狠一點直接掛了它。

附帶一提, ctrl + c 是送出 SIGINT。

執行 signal handler 的時機

process 得先拿到 CPU 才能執行 signal handler, 換句話說, 若 process P 處於 stop 的狀態 (D、S、T), 或系統太忙撥不出時間給它, 即使已送出 SIGTERM 給 P 了, P 也無法處理。而送 signal 的一方只能由 signal system call 的返回值判斷 P 仍活著, 有成功送出 signal, 無法得知 P 何時能處理它。

特別的是, SIGKILL 一送出對方就掛了, 不用取得 CPU 再掛掉。沒看到有特別的文獻指出 SIGKILL 這點特別的行為。man 7 signal 只有指出「The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored」。就實用角度來看, 讓 SIGKILL、SIGSTOP 立即生效, 確實比較合理。

SIGHUP 的行為

terminal 斷線 (hangup) 時, terminal 的主控 process 會收到 SIGHUP。而它的預設行為是終結程式, 所以關掉 terminal 時, 裡面的程式會直接結束。

bash 和 ksh 在結束的時候會送 SIGHUP 給背景程式, 若背景程式也沒寫 SIGHUP handler, 那它們也會一起結束。這是關掉 terminal, 全部程式會一起結束的原因。

要避免這個行為, 可用 nohup 執行程式, 它會做 I/O 重導、執行 signal (SIGHUP, SIG_IGN), 然後執行目標程式。或是用 bash 的 disown -h, 再放到背景跑, 或用 gdb attach process, 再輸入 handle SIGHUP nopass。

用 SIGQUIT 產生 core dump

在 terminal 按 ctrl + \ 時會送出 SIGQUIT 給前景程式, 這個 signal 的作用是要就該程式自我了結並產生 core dump。當然, 一些設定要先設好, 才會有 core dump。

這有許多好處:

• 程式進無窮迴圈時按 ctrl + \, 再用 gdb 列 backtrace 看卡在那。雖說直接 用 gdb attach 也 ok。若高中練 ACM 知道這個方法, 可省下一些除錯時間 (遠目)。
• 方便測試 core dump 設定, 不用另寫個小程式故意寫入不合法的位置。

Linux 的 capability

昨天看 TLPI ch39 才知道 Linux 有 capability 可依項目授權, 不用像以前那樣, 使用 setuid 一次大放送。像 passwd 就是 setuid 的典型使用情境, 要讓所有使用者能改自己的密碼, 所以他們要有權限存取密碼檔, 但又不能讓使用者做超出他們該做的事。於是, 使用 setuid 的程式需要很小心地設計, 避免給太多權限, 或是被 cracker 攻破取得 root 權限。

看到 capability 如此地威, 不禁納悶有多少程式有使用 capability, Scott 提供一個不錯的找法: 用 package 管理套件找出有那些程式依賴 capability 的套件, 就知道了。Ubuntu 對應的指令是 apt-rdepends -r libcap2, 也不算少, 有 100 多個套件用到 libcap2。

用 strace 找出 Ubuntu 如何提示未安裝的指令

在 Ubuntu 下執行指令後, 若沒有安裝指令的話, 會出現提示:

$ apt-rdepends
The program 'apt-rdepends' is currently not installed.  You can install it by typing:
sudo apt-get install apt-rdepends

但若直接用 bash 執行, 卻不會有這效果:

$ bash -c apt-rdepends
bash: apt-rdepends: command not found

以前覺得很好奇, Ubuntu 怎麼做到這件事的, 知道 strace 以後, 追這類原因簡單許多, 只要有輸入和輸出訊息, 就可夾擊出一些線索。

• 在 terminal 1 輸入 echo $$ 取得該 bash 的 PID
• 在 terminal 2 輸入 sudo strace -obash.trace -f -s512 -p PID
  • -obash.trace 表示將輸出存到 bash.trace, 訊息很多, 通常都會寫到檔案裡
  • -s512 表示輸出訊息最多到 512, 預設行寬有點短, 之後不方便找輸出的訊息
  • -f 表示一起追蹤 child process, 這點很重要, 沒加 -f 就追不到 bash 使用的其它子程序, 而關鍵就在 bash 叫起的子程序
  • -p PID 表示追踪其它 process, 照理說同一個使用者不用 root 權限應該也能看, 不知為啥不通
• 在 terminal 1 輸入 apt-rdepends, 因為 strace 有用 "-f", 速度會慢很多。等待指令完成
• 在 terminal 2 按 Ctrl+C 中斷 strace, 觀察 bash.trace

搜一下 "apt-rdepends" 會看到 bash 在嘗試各種 path 後都找不到檔案:

16520 stat("/home/fcamel/bin/apt-rdepends", 0x...) = -1 ENOENT...
16520 stat("/usr/local/sbin/apt-rdepends", 0x...) = -1 ENOENT...
16520 stat("/usr/local/bin/apt-rdepends", 0x...) = -1 ENOENT...
16520 stat("/usr/sbin/apt-rdepends", 0x...) = -1 ENOENT...
16520 stat("/usr/bin/apt-rdepends", 0x...) = -1 ENOENT...
16520 stat("/sbin/apt-rdepends", 0x...) = -1 ENOENT...
16520 stat("/bin/apt-rdepends", 0x...) = -1 ENOENT...
16520 stat("/usr/games/apt-rdepends", 0x...) = -1 ENOENT...
16520 stat("/home/fcamel/bin/apt-rdepends", 0x...) = -1 ENOENT...
16520 stat("/home/fcamel/bin/apt-rdepends", 0x...) = -1 ENOENT...

之後在別的 child process 呼叫外部程式執行 /usr/lib/command-not-found:

16877 execve("/usr/bin/python", ["/usr/bin/python", "/usr/lib/command-not-found", "--", "apt-rdepends"], [/* 38 vars */]) = 0

若想研究怎麼找出該裝的套件, 可以研究 "/usr/lib/command-not-found"。若想研究 bash 如何判斷在有 terminal 的情況下要多找安裝的指令, 可以自己編含 debug symbol 的 bash, 再用 gdb 找出相關位置, 再讀附近的原始碼。這樣一來, 至少知道需要追的時候該如何進行, 剩下就是增加經驗提昇追程式的速度了。

2012-01-23 更新

經 wens 提醒, 原來是用 bash 的 hook 做的, 見 /etc/bash.bashrc 了解設定, man bash 在 COMMAND EXECUTION 那節有說明。

gdb 如何找到 debug symbol

先前在《追踪 glibc 裡的程式》提到自己如何亂試, 試出讓 gdb 讀到 debug symbol。昨天聽 Scott 說明, 才知道背後是怎麼一回事。

在 Ubuntu 下以 libm 為例, 在 /lib/x86_64-linux-gnu/libm-2.13.so 裡面, 先看一些相關的 section header:

$ objdump -h /lib/x86_64-linux-gnu/libm-2.13.so | grep gnu
/lib/x86_64-linux-gnu/libm-2.13.so:     file format elf64-x86-64
  0 .note.gnu.build-id 00000024  0000000000000238  0000000000000238  00000238  2**2
  2 .gnu.hash     00000fa4  0000000000000280  0000000000000280  00000280  2**3
  5 .gnu.version  00000298  00000000000038da  00000000000038da  000038da  2**1
  6 .gnu.version_d 0000005c  0000000000003b78  0000000000003b78  00003b78  2**3
  7 .gnu.version_r 00000030  0000000000003bd8  0000000000003bd8  00003bd8  2**3
 27 .gnu_debuglink 00000014  0000000000000000  0000000000000000  000840e4  2**0

幾個重點

• .note.gnu.build-id 表示 binary id, 之後用來比對 debug symbol 是否出自 shared lib。看起來 Fedora 在找 debug symbol 時, 有用到 binary id; 而 Ubuntu 沒有的樣子, 我用 hexedit 亂改這個 section 的值, 仍能找到 debug symbol
• .gnu_debuglink 指向包含 debug symbol 的檔案, 若用 hexedit 改掉它的值, 執行 gdb /lib/x86_64-linux-gnu/libm-2.13.so, gdb 會表示找不到 libm 的 debug symbol
• 可用 objdump -s -j .gnu_debuglink /lib/x86_64-linux-gnu/libm-2.13.so 顯示 section 內容

若用 LD_PRELOAD=/usr/lib/debug/lib/x86_64-linux-gnu/libm-2.13.so ANY_PROGRAM 執行程式, 結果會 segmentation fault, 所以我推測 Ubuntu 下 X-dbg 裡包的檔案, 可能和 Fedora 一樣, 只有 debug symbol 而不是完整 strip 前的函式庫。不知要如何確認該檔案裡只有 debug symbol 沒有實際的 object code。

至於確認原本的 binary (object file / shared lib / executable) 是否有編入 debug symbol, 除了用 objdump -S 再找看看有沒有出現程式碼外, 更簡單的作法是用 objdump -h | grep debug:

$ objdump -h /usr/lib/debug/lib/x86_64-linux-gnu/libm-2.13.so | grep debug
/usr/lib/debug/lib/x86_64-linux-gnu/libm-2.13.so:     file format elf64-x86-64
 28 .debug_aranges 00004770  0000000000000000  0000000000000000  000002b0  2**4
 29 .debug_pubnames 00002e44  0000000000000000  0000000000000000  00004a20  2**0
 30 .debug_info   000318ee  0000000000000000  0000000000000000  00007864  2**0
 31 .debug_abbrev 00010fc3  0000000000000000  0000000000000000  00039152  2**0
 32 .debug_line   00018c20  0000000000000000  0000000000000000  0004a115  2**0
 33 .debug_str    000041bc  0000000000000000  0000000000000000  00062d35  2**0
 34 .debug_loc    00062bc5  0000000000000000  0000000000000000  00066ef1  2**0
 35 .debug_pubtypes 00003a11  0000000000000000  0000000000000000  000c9ab6  2**0
 36 .debug_ranges 00003e30  0000000000000000  0000000000000000  000cd4c7  2**0

有上述 section 的話, 表示有含 debug symbols。

備註

1. hexedit 基本指令

• F1: 等同於 man hexedit
• F4: 跳到 offset, 對照 objdump -h X 看倒數第二欄使用
• TAB: 切換 hexadecimal 或 ascii 區, 之後取代內容或搜尋, 和這有關
• 直接在 byte 上打字取代
• /: 找字串
• ctrl+c / ctrl+x: 離開 / 存檔離開

2. 見《The DWARF Debugging Standard》了解 debug 資訊如何存在檔案, 只是留著備忘, 目前應該沒必要去讀。

3. 若是自己編含 debug symbol 的函式庫, 就不是上述那一回事了, 而是直接編進目前的函式庫裡。

4. 《Separate Debug Files - Debugging with GDB》說明 gdb 如何支援分離 debug symbol 到另一個檔案, 另外 man strip 或 man objcopy, 可在 "--only-keep-debug" 的部份看到相關說明。看來要知道到底各個 distribution 怎麼做這事, 去看該 distribution 官方的說明會比較確實。之後再看看吧。

iPad 升級到 iOS 5

不知是否因為和 command 一樣人品不好, 用 Apple 的產品總遇到一堆鳥事, 讓我對 Apple 產品難以建立好感。

照官網和 google 大部份人的說法來看, 就 iTunes 升到 10.5, 將 iPad 接上去, 在 iTunes 裡按 check for update 即可。但 iTunes 回報 This version of the iPad software (4.2) is the current version。

有人提到可嘗試手動升級, 下載好 firmware 檔後, 照著指示手動選檔案 restore, 結果出現 "this device isn't eligible for the requested build"。google 看到有許多人提到類似問題, 但有些是 jail break 造成的, 提到的解法看來也不適用於我的情況, 況且我用的 iPad 應該沒 JB。

最後在 restore mode 下, 成功地升到 iOS 5.x 了, 太感謝這個影片, 操作方式講解得非常清楚: 《How to Enter DFU Mode | Restore Mode - Get Out of DFU Mode | Restore Mode - Fast, Safe & Easy - YouTube》。

自行編譯含 debug symbol 的套件 (package)

對函式庫 X 來說

• X-dev 表示讓開發者用的, 有裝 header、文件之類的
• X-dbg 內容類似 X, 不過有留 debug symbol

比方說 libjpeg, 三種的描述如下:

• libjpeg62 - The Independent JPEG Group's JPEG runtime library
• libjpeg62-dbg - Development files for the IJG JPEG library
• libjpeg62-dev - Development files for the IJG JPEG library

裝了 X-dbg 後什麼事也不用做, gdb 自己會優先用含 debug symbol 的版本。不過若官方沒提供供 X-dbg 的話, 就得自己編。參考官方文件《HowToGetABacktrace - Debian Wiki》, 做法如下:

• $ apt-get install build-essential fakeroot gdb
• $ apt-get build-dep X
• $ DEB_BUILD_OPTIONS="nostrip noopt" fakeroot apt-get -b source X
• $ dpkg -i X.deb

針對上述指令, 補充幾點

• 編好套件後, 可用 dpkg -c X.deb 先看裡面裝了什麼
• 用 objdump --source FILE 查看裡面有沒有含程式碼, 有的話才表示確實有含 debug symbol。這個作法比用 file FILE 看是否有 strip 更確實。二進位檔有可能沒含 debug symbol 也沒 strip。

2016/02/16 更新

遇到 "trying to overwrite ..." 的錯誤 時，可以用 sudo dpkg -i --force-overwrite X.deb 強制安裝。

Python debug 的方法

有別於 C/C++, Python 通常會有原始碼, 除非套件提供者無腦地用 egg 包裝, 不然應該滿好改程式碼的 (我討厭 egg!! 其實這有雙關, 不過 ...)。再加上使用 virtualenv 擁有自己安裝的函式庫, 這樣和別人共用 server 時, 不用擔心改函式庫的程式會影響到別人, 相當方便。

在這樣方便改程式的情況下, 通常我會採下列三種方法之一來觀察程式 (或除錯):

使用 IPython

在要觀察程式的地方寫入

import IPython
IPython.Shell.IPShellEmbed(argv=[])()  # 舊版
IPython.embed()                        # 新版

我甚至寫了個 vim 巨集展開這段。

使用 pdb

import pdb; pdb.set_trace()

效果類以上一個, 不過應該是 ipython 更易操作。或許也可考慮用 IPython pdb。習慣用 gdb 看 backtrace 的話, 用 pdb 滿直覺的。

使用 logger

配合 decorator 的語法, python 要觀察特定函式容易許多, 如這篇提到的做法, 寫個 decorator "log", 配合 lazy initialization 的方式設定 logging。之後只要在有興趣的幾個函式上加個 @log 即可。

這個作法應用的範圍更大, 像在 WSGI 沒 console 可用, 也不能輸出到 STDOUT, 用這招就沒問題。還有, 這個作法也可在 production 環境記錄關鍵函式的執行速度, 協助 profiling。

題外話

若是要除錯的話, 視情況用 unit test 會更好, 原因見《為什麼要寫 unit test？為什麼要先寫測試？》。在見識過 C/C++ 的困難處後, 覺得在 Python 的環境裡寫 test 實在是太輕鬆寫意了, 雖說寫 test 確實還是有它的難處, 不過該寫的東西之前寫得差不多了, 有興趣的人請翻翻舊文。

VirtualBox 改變 vdi 的大小

花了一整個晚上的血淚談。

注意事項

• 目前 (4.x) 只支援在沒有 snapshots 的情況下改變 vdi 大小
• 若目前有用 snapshot, VBoxManage 也不會阻止你改變大小, 只是改完就沒救了, 會無法刪掉最早的 snapshot, 推測是因為硬碟上的 vdi 檔案資訊和 snapshot 內的 vdi 不合。可以刪除中間的 snapshot, 因為那沒有涉及硬碟上的 vdi 檔

擴大 vdi

• 關掉 guest OS
• 砍掉所有 snapshot, 只剩 current state: 在命令列下使用 VBoxManage modifyhd --resize NUM_MB /path/to/vdi
• 用 Ubuntu CD 開機 (現在已沒有 "live CD" 的名稱了, Ubuntu 安裝光碟本身就可當 "live CD"), 使用 gparted 調整硬碟大小
• 重開 guest OS, 可用 df -h 確認實際大小確實有改變 (或用 sudo fdisk -l /dev/sda 看 partition 資訊)。

若不幸在砍 snapshot 前先用 VBoxManage 改了大小, 就無解了。目前只有看到一位仁兄用 Mac 的 Time Machine 還原到他做蠢事前的狀態, 解決這個砍不掉的問題 ... 。

我用另一台電腦的 VirtualBox 實驗以上步驟沒有問題, 確認問題出在我先改了 vdi 大小。

縮小 vdi

我沒試過這個, 順便筆記一下

• VBoxManage --resize 只支援擴大, 要縮小的話要換指令
• 先在 guest OS 針對要縮小的 partitoin, 用對應的工具重整 partition (zerofree on Linux)
• 使用指令 VboxManage modifyhd --compact /path/to/vdi

參考資料

下次用這類 VM 的指令, 一定要熟讀手冊再下手啊 ...

• 《VBoxManage modifyhd》
• 《Trivial Proof: Resizing a VirtualBox Virtual Hard Disk》
• 《virtualbox.org: Can't delete top snapshot or expand HD size in VB 4.0.12》

gdb 初步心得

對初學者來說, 最好有個針對常用情境的簡單指南, 之後有閒再看落落長的教學。這裡列一下最近常用的功能, 之後再慢慢更新。

前置動作

• gcc/g++ 編譯時要加 -g
• 要觀察用到的函式庫, 則要裝 x-dbg 版 (如 libjpeg62 -> libjpeg62-dbg), gdb 會優先載入 debug 版函式庫。並且需要用 directory 載入原始碼, 詳情見《追踪 glibc 裡的程式》的說明。
• 若原始碼的位置和當初編 binary 時的位置不同 (常有的事), 可用 set substitute-path from to 做路徑字串取代。
• 可用 objdump --source FILE 確認是否真的有編到 -g。有的話可以在輸出裡看到程式碼。

雖說通篇我都寫 gdb, 但是 cgdb 好用許多, 推薦使用。聽 command 說 vimgdb 更好用, 不過要 patch vim 後才能用, 就 ... 先備忘吧。

執行方式

從頭執行

• bash> gdb --args PROGRAM PROGRAM-ARG1 ...
• gdb> start # 進入 main 後停下來

檢查掛點原因 (參考《產生 core dump 的方法》確保有 core dump)

• bash> gdb PROGRAM CORE
• gdb> bt 20 # 看掛掉的 call stack 最底層 20 個 function call

通常載入 PROGRAM 讀 debug symbol 較花時間, 我習慣用 gdb PROGRAM 進 gdb 後, 再用 core CORE 指令看不同的 core dump。

若希望從頭重來, 有設好中斷點就用 r, 沒有則繼續用 start, 不用離開 gdb, 可簡省載入 PROG 的時間。

設中斷點

• b LOC # 設中斷點, 或用 cgdb 直接在程式視窗按空白鍵
• i b # 列出全部中斷點
• d NUM # 移除編號 NUM 的中斷點
• save breakpoints FILE # 存下目前設的中斷點到檔案 FILE
• so FILE # 載入之前設的中斷點
• dis 1-10: 暫停使用 breakpoints 1-10。
• ena 1-10: 恢復使用 breakpoints 1-10。

關於 LOC: 見《Specify Location - Debugging with GDB》。我比較常用 filename:linenum、linenum 或 +N。因為不易對到 C++ 的函式名稱, 所以我都用行號。

我還沒有適當情境試 conditional break, 但應該很有用, 備忘。

移動

• n # 跳下行
• s # 若有函式, 跳進去; 反之則同 n
• fin # 執行到函式結尾, 返回上一層
• until LOC # 執行到 LOC 再停, 我以前都傻傻的先設中斷再按 c ...
• c # 執行到下個中斷點
• 跳過下一行程式 (ref.), 記得要設中斷點才行
  
  • b +1
  • j +1
• ret # 不執行函式剩下的程式, 直接返回上層 frame
• ps. 按 Enter 可重覆上個指令, 在移動指令時和切 stack frame (後述) 時特別好用

在 call stack 之間移動

• up # 往上移一個
• do # 往下移一個
• f N # 跳到 stack frame N

觀察值

• p EXPRESSION # 印出 EXPRESSION 的值, 可是變數、函式等
• 印出 smart pointer 的值 (ref.): 得先取出裡面的 pointer 再取出它的 member function / field
• whatis VAR # 看型別
• ptype VAR # 看型別的宣告內容, 了解有那些欄位可讀
• p P@N # 印出位置 P 開始 N 個變數的值
• p *P@N # 印出對位置 P 開始 N 個變數取值後的值
• p *argv@argc # 在 main() 函式裡執行這指令, 會印出命令列參數內容

thread

• i thr # 列出目前的 thread, 建議事先用 prctl / pthread_setname_np 設定 thread name, 比較好辨別
• thr NUM # 切換 thread

其它

• set var X = ... # 執行期間改變變數 X, 以在執行期驗證小修改是否有效, 簡省編譯時間
• handle SIGSTOP nostop noprint # 收到 SIGSTOP 時不要停且不要輸出訊息, 在 Android 環境有時 gdb 會莫明地一直收到 SIGSTOP

參考資料

• 《Debugging with GDB》: 待用一陣子後再來掃一遍, 挑出有用的東西

進階指令

• commands BREAKPOINT_ID: 定義在進入 breakpoint 後, 執行一系列指令, 比方 "p some_var; c"。
• define NEW_CMD: 類似函式, 定義由一堆指令組成的新指令。

追踪 glibc 裡的程式

這篇是一堆試誤心得的中間記錄, 使用的版本是 Ubuntu 11.04。

失敗的作法

• 在 link 時, 用 -L/usr/lib/debug/lib/x86_64-linux-gnu/ 改變 link 到的 libc.so, 但沒有效果。用 strace -e open 觀察 gcc 做的事, 發現是因為 /usr/lib/debug/lib/x86_64-linux-gnu/ 下沒有 libc.so, 而是 libc-2.13.so。之前沒學清楚 -L 和 -l 的細節, 耍笨。
• 由 man ld.so 得知可用 LD_LIBRARY_PATH 或 LD_PRELOAD 在執行期換掉 libc.so, 但是也沒有效果。用 LD_PRELOAD 換成 debug 版 libc.so 時, 跑 gdb 會 segmentation fault

成功的作法

前置作業

• $ sudo aptitude install libc6-dbg # 取得有 debug symbol 的 libc.so
• $ apt-get source libc6-dev # 取得原始碼目錄 eglibc-2.13

執行

1. $ gcc myprog.c -g -o myprog
2. $ gdb myprog
3. $ directory /path/to/eglibc-2.13/stdio-common/
4. $ start # 跑到 main 就停下來

然後 gdb 會神奇地去找含 debug symbol 的 libc, 後面就可以用 step 進入 glibc 的函式。不知這個行為寫在那裡, 或許可以從 gdb 原始碼找出來吧。

若有進入但說找不到原始碼, 表示沒有告知 gdb 正確的原始碼位置, 到 eglibc-2.13 下找一找, 再回來用 directory 設位置。

另外在用到 sqrt()、log() 時也是如此, 照一樣的編法 gcc myprog.c -g -lm -o myprog, 然後在 start 後, gdb 會去找 debug 版的 libm.so。不過要記得多執行 directory /path/to/eglibc-2.13/math 載入 math 的原始碼, gdb 才能列出原本的程式。用 ldd 觀察 myprog 也驗證原本的執行檔將 libc 和 libm 連到沒有 debug symbol 的版本。

另外試了直接和 debug 版的 libc.so 或 libm.so 編在一起 (gcc myprog.c -g /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.13.so), 但是一跑就會 segmentation fault。

另外有些函式好像是用組語寫的, 看不懂它們的行為, step into sqrt 沒有效果。

結論

要觀察 glibc 的行為, 要做以下的事:

• 裝 libc6-dbg, 取得含 debug symbol 的 shared lib
• 用 apt-get source libc6-dev 取得原始碼。由於 glibc 裡有多個 shared lib, 要先 grep 找看看想觀察的程式放在那個目錄下, 跑 gdb 時再用 directory 載入該目錄, 相對路徑才會對。

2012-01-10 更新: 補充觀察 gdb 找 debug lib 的行為

一樣可以用老招 strace -e open 跑 gdb 看出背後發生的事, 以下是沒有裝 libc6-dbg 跑出的訊息:

$ strace -e open -o gdb.trace gdb myprog

然後執行 tail -f gdb.trace | grep libc 觀察行為。

以下是執行 start 以前的訊息:

open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY) = 3
open("/lib/libcrypto.so.0.9.8", O_RDONLY) = 3
open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)

以下是執行 start 以後的訊息:

open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY) = 6
open("/lib/x86_64-linux-gnu/libc-2.13.so", O_RDONLY) = 7
open("/lib/x86_64-linux-gnu/.debug/libc-2.13.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/debug//lib/x86_64-linux-gnu/libc-2.13.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/debug/lib/x86_64-linux-gnu/libc-2.13.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc-2.13.so-gdb.py", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/debug/lib/x86_64-linux-gnu/libc-2.13.so-gdb.py", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/gdb/auto-load/lib/x86_64-linux-gnu/libc-2.13.so-gdb.py", O_RDONLY) = -1 ENOENT (No such file or directory)

可以看出 gdb 不論如何, 都會試著載入 debug 版的函式庫, 來執行目標程式。找不到的時候, 自然就是用沒有 debug symbol 的函式庫。

2012-01-22 更新

在《gdb 如何找到 debug symbol》有進一步說明。

2016-02-16 更新

若 Ubuntu 沒有附 X-dbg 的 package，可以自己編原始碼裝進去，詳見 自行編譯含 debug symbol 的套件 (package)

寫 blog 的目的

一開始寫這個 blog, 是為了備忘以及分享一些小心得。一兩個月才寫個一篇主站的文章, 很多小東西就這樣流失了, 有點可惜。

昨天和 Scott 在這裡聊到寫這 blog 的目的, 順手貼過來:

我寫 blog 除備忘外, 主要是想記錄「思考解決問題」的路徑。比方說「了解背後運作原理」、「用什麼工具觀察出背後運作機制」、「從什麼角度思考可能的原因並做驗證」。有時是缺少背景知識、有時是缺少關鍵工具, 以致於無法完成一個看似困難實則簡單的事。

以前很想知道某些問題怎麼解, 但是太拉里拉雜, 很難問, 問了別人, 別人只會說答案, 也不太知道怎麼說明背後的思路, 已成為他們的習慣了。

沒想到這樣隨手寫了兩年, 意外地寫出新的心得, 才發覺我想寫的東西為何。

一秒設好慣用的環境

sudo apt-get install git && git clone git://github.com/fcamel/configs.git && cd configs && ./install.sh

不是想發一行文, 而是想強調 open repository 真方便。

熟悉系統工具好處多多

記一下以前很困擾, 現在秒殺的小事。

更新這篇的時候, 忘了函式庫用的 man page 裝在那個 package。以前就會想辦法 google, 運氣好一下會找到, 運氣不好會多找一會兒。

這回我想到新作法:

$ strace -e open man 3 printf > /dev/null
# 發現是讀 /usr/share/man/man3/printf.3.gz

$ dpkg --search /usr/share/man/man3/printf.3.gz
# 找到套件名稱 manpages-dev

$ aptitude show manpages-dev
# 確認描述符合, 收工

從 C 呼叫 C++ 函式的過程理解程式編譯、連結的原理

今天做了一個錯誤的決定, 想說在一堆 C 程式裡呼叫另一堆 C++ 程式。邊弄邊學, 最後發現什麼都沒改的情況, 改用 g++ link 原本的 C 程式就會爆炸。想想還是撿要用的一小部份程式出來, 另寫 C 的程式比較單純。不過也藉這機會, 才讓我真的搞懂這之中發生什麼事。

先附上要用的範例, 再來慢慢廢話, 沒耐心的人直接玩範例可能就懂了。

原始碼

/* b.h */
#ifndef _B_H_
#define _B_H_

#ifdef __cplusplus
extern "C" {
#endif
int add(int a, int b);
#ifdef __cplusplus
}
#endif
#endif

/* b.cpp */
#include "b.h"

int add(int a, int b) {
    return a + b;
}

/* a.c */
#include <stdio.h>
#include "b.h"

int main(void) {
    printf("%d\n", add(3, 5));
    return 0;
}

編譯方式

$ gcc -c a.c
$ g++ -c b.cpp
$ g++ a.o b.o -o a
$ ./a                    # 輸出 8

說明

《How to mix C and C++  Updated! , C++ FAQ》將 C 和 C++ 互相呼叫的各式注意事項寫得相當清楚, 不愧為 FAQ 啊! 其中在 C 呼叫 C++ 的函式時, 要注意幾點 C++ 有 name mangling, 也就是不管是 class method 還是 function, 名稱 X 編出來都不會是 X, 而 C 通常沒有 name mangling。不過不管 C 是否有 name mangling, 關鍵是讓 C 能用 C 的方式認得 C++ 的 symbol。

先明白編譯、連結時發生了什麼事, 從這裡出發, 可知要讓 C 呼叫到 C++ 的函式, 要從幾個地方下手:

1. C、C++ 都需要它們各自的 header, 才能編成 object code。編譯時 symbol 仍不用存在
2. 用 gcc 編 C 程式; 用 g++ 編 C++ 程式。雖說是很自然的事, 對兩者都不熟的我, 一開始還真沒想到。
3. 連結 object code 時, C 要能找到 C++ 的函式
4. 既然要連結 C++ 的 object code, 連結時自然要用 g++

回到前面的範例:

• 寫 b.h 時用 #ifdef __cplusplus 讓 a.c 和 b.cpp 都能 include b.h, 且看到不同的東西。可用 gcc -E、g++ -E 查看前置處理器展開的結果, 見證騙術的最高境界, 同時滿足兩方的需求, 而且還沒有查覺到對方的存在!!
• 編譯 b.cpp 時, 透過 b.h 加入 extern "C", 這樣才不會做 name mangling。用 nm b.o 查看, 會發現有 name mangling 時是 _Z3addii, 反之則是 add (ps. 經 Scott 提醒, 可用 c++filt demangle symbol)
• 由於 C 沒有 extern "C" 的語法, b.h 裡面有這段的話會編譯錯誤, 透過 ifdef 避開。編譯 a.c 沒什麼特別的, 騙它有 add 這個 symbol 即可。

連結時很單純, 先前在編 .o 時確保 b.o 裡可以找到 a.o 認得的名稱 add, 再來記得只有 g++ 同時認得 a.o 和 b.o 的格式, 就沒什麼問題了。

另外, 若想用 C++ 的 class method, 得先包成 C++ function 才行。傳遞物件的話, 參考 FAQ 的說明, 有些注意事項, 待要用到時再來細看。

2012-01-30 更正

gcc 和 g++ 都是呼叫 ld, 只是傳的參數不一樣, 我原本的說法「只有 g++ 同時認得 a.o 和 b.o 的格式」並不正確。還沒有仔細研究 ld, 推測 ld 應該沒有區別 object file 是怎麼被產生的。

透過 /proc/PID/task/ 觀察 multi-thread 狀態

為了搞清楚程式、用到的函式庫等到底有沒有用到 multi-thread, 以及各 thread 的狀態如何變化等, 查了一下相關資訊。

在 man ps 裡沒看到適合的參數, ps -eLf 沒有列出 thread 的執行狀態。這頁 man page 太複雜, 看一看決定改看 man proc, 反正 ps 也是讀 /proc/PID 的資訊。

順著 "thread" 的關鍵字掃完 man proc, 看到 /proc/PID/task/ 有記錄擁有的 thread 資訊, 其中每一個目錄 /proc/PID/task/TID/有類似 /proc/PID/ 的資訊, 而 /proc/PID/task/TID/status 裡面有我要的東西。所以就寫了個小程式 thstate 來觀察行為, 試用後頗順利地達成階段性目標。/proc 真是好東西, 為啥以前都沒留意到呢 ...。

2012/01/05 更新

看到 wens 提到可混用 ps aux -L, 這樣就有 LWP (thread id) 了, 不過沒有 PPID。又查了一下 man page, 發現可用 -o 自訂格式, 這樣用

ps awxo pid,ppid,pgid,nlwp,lwp,stat,comm

就有符合我需求的材料了, 再配合 grep PID 即可。不過既然已寫好了客製化的 script, 還是用 script 比較順手一些。

2012/01/05 再更新

看到 Scott 提到可用 ps u -Lp PID, 終於湊出「終極」指令。上面的描述就當記錄吧, 也反映出軟體開發的常態, 工程師常常找不到想要的東西就開始自己重造輪子, 造好後才發現原來其實有更好的方案, 只是之前沒有看到 ...。

ps -Lo pid,ppid,pgid,nlwp,lwp,stat,command -p PID

debug info 和 optimization

要知道程式有沒有編進 debug info, 可用 objdump --source BINARY | less 觀察。若有看到程式碼的內容, 表示有編進去。另外要注意的是, 程式本身和用到的函式庫編法可能不同, 可能程式有加 -g, 但函式庫沒有。造成看得到一些函式內容, 卻看不到另一些的內容。

另一個要注意的點是, 今天聽 wens 說才知道編程式時可以同時用 -O 和 -g。這樣做的好處是, 執行速度快, 接近 production 運作的情況。我自己試用的感覺是, 有些 bug 在 debug mode 可能不方便重制出來, 還有 debug mode 通常跑比較慢, 所以用 -O -g 還滿方便的。但不幸的是, 兩者合用會有一點副作用, 在 man gcc 裡有說明:

GCC allows you to use -g with -O. The shortcuts taken by optimized code may occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values were already at hand; some statements may execute in different places because they were moved out of loops.

Nevertheless it proves possible to debug optimized output. This makes it reasonable to use the optimizer for programs that might have bugs.

當程式是用 -O 和 -g 編出來的時候, 用 objdump --source 會看到程式碼怪怪的, gdb 執行順序也會怪怪的, 執行行為和程式碼有時有一點出入, 還有部份的值會印不出來, gdb 輸出 value optimized out。若要觀察的東西就是那些部份, 就得回頭用 -O0 -g 確保沒有開啟最佳化。