A. 如何快速查找C語言代碼中的宏的值
很多的系統，代碼量超大，在我們閱讀其代碼的時候，往往macro能決定代碼執行的具體分支。利用find grep查找起來會特別慢，而且不一定能找到正確的值。如果系統是可編譯的，可以利用編譯器的預處理功能很快知道宏的具體值。
方法如下：
在CFLAGS裡面添加 -E 選項。
舉例說明：
在android 系統裡面,
1. 在Andriod.mk裡面添加-E 參數。
LOCAL_CFLAGS += -E
2.重新編譯，顯示其過程
mm showcommands
3.編譯過程會列印出類似下面的結果。
prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-gcc -I hardware/ttd/marvell/generic/bmm-lib/lib -I out/target/proct/OMS_TTD/obj/SHARED_LIBRARIES/libbmm_intermediates -I system/core/include -I hardware/libhardware/include -I hardware/libhardware_legacy/include -I hardware/ril/include -I dalvik/libnativehelper/include -I frameworks/base/include -I frameworks/base/opengl/include -I external/skia/include -I out/target/proct/OMS_TTD/obj/include -I bionic/libc/arch-arm/include -I bionic/libc/include -I bionic/libstdc++/include -I bionic/libc/kernel/common -I bionic/libc/kernel/arch-arm -I bionic/libm/include -I bionic/libm/include/arch/arm -I bionic/libthread_db/include -c -fno-exceptions -Wno-multichar -msoft-float -fpic -ffunction-sections -funwind-tables -fstack-protector -fno-short-enums -march=armv5te -mtune=xscale -D__ARM_ARCH_5__ -D__ARM_ARCH_5T__ -D__ARM_ARCH_5E__ -D__ARM_ARCH_5TE__ -include system/core/include/arch/linux-arm/AndroidConfig.h -I system/core/include/arch/linux-arm/ -mthumb-interwork -DANDROID -fmessage-length=0 -W -Wall -Wno-unused -Winit-self -Wpointer-arith -Werror=return-type -Werror=non-virtual-dtor -Werror=address -Werror=sequence-point -DNDEBUG -g -Wstrict-aliasing=2 -finline-functions -fno-inline-functions-called-once -fgcse-after-reload -frerun-cse-after-loop -frename-registers -DNDEBUG -UDEBUG -DLOG_DISABLEDEBUG=1 -mthumb -Os -fomit-frame-pointer -fno-strict-aliasing -finline-limit=64 -E -MD -o out/target/proct/OMS_TTD/obj/SHARED_LIBRARIES/libbmm_intermediates/bmm_lib.o hardware/ttd/marvell/generic/bmm-lib/lib/bmm_lib.c
其中-o 是生成的文件。
打開這個文件，就是我們預編譯的結果，可以很清晰地看到各個宏的具體值。
B. ubuntu 驅動編譯無法通過 求神來解決
復制代碼
1 #ifndef __KERNEL__
2 # define __KERNEL__
3 #endif
4 #ifndef MODULE
5 # define MODULE
6 #endif
7
8 // 下面的是主要的內容
9 #include <linux/kernel.h>
10 #include <linux/mole.h>
11 #include <linux/init.h>
12
13 MODULE_LICENSE("GPL");
14
15 static int year=2012;
16
17 int hello_init()
18 {
19 printk(KERN_WARNING "Hello kernel, it's %d!\n",year);
20 return 0;
21 }
22
23
24 void hello_exit()
25 {
26 printk("Bye, kernel!\n");
27 }
28
29 // 下面兩個為關鍵的模塊函數
30 mole_init(hello_init);
31 mole_exit(hello_exit);
復制代碼
如果上面的代碼看起來不太熟悉，那麼需要查看以下相關的書籍，比如《Linux設備驅動程序，第三版》，也就是大名鼎鼎的LDD；
2、老式驅動模塊編譯方法：
直接寫出make規則到makefile文件中，引用內核體系的頭文件路徑，舉例如下：
復制代碼
1 # The path of kernel source code
2 INCLUDEDIR = /media/GoldenResources/linux/linux-2.6.30/include
3
4 # Compiler
5 CC = gcc
6
7 # Options
8 CFLAGS = -D__KERNEL__ -DMODULE -O -Wall -I$(INCLUDEDIR)
9
10 # Target
11 OBJS = hello.o
12
13 all: $(OBJS)
14
15 $(OBJS): hello.c
16 $(CC) $(CFLAGS) -c $<
17
18 install:
19 insmod $(OBJS)
20
21 uninstall:
22 rmmod hello
23
24 .PHONY: clean
25 clean:
26 rm -f *.o
復制代碼
這里有我是用的一個linux內核源代碼路徑：/media/GoldenResources/linux/linux-2.6.30/include ，注意設置到正確的源碼路徑。
嘗試這編譯：
復制代碼
$make
gcc -D__KERNEL__ -DMODULE -O -Wall -I/media/GoldenResources/linux/linux-2.6.30/include -c hello.c
In file included from /media/GoldenResources/linux/linux-2.6.30/include/linux/kernel.h:11:0,
from hello.c:8:
/media/GoldenResources/linux/linux-2.6.30/include/linux/linkage.h:5:25: fatal error: asm/linkage.h: No such file or directory
compilation terminated.
make: *** [hello.o] Error 1
復制代碼
C. 如何編譯libcurl
1. Android
1.1配置
將curl源文件加到在Android源代碼external/curl/中。創建shell腳本configure.sh，並把它放到external/curl/中。
腳本內容如下：
#!/bin/sh SDK_ROOT=/home/nudtzxm/android_sdk export PATH="$SDK_ROOT/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin:$PATH" ./configure --host=arm-linux CC=arm-eabi-gcc \ CPPFLAGS="-I $SDK_ROOT/system/core/include -I $SDK_ROOT/hardware/libhardware/include -I $SDK_ROOT/hardware/libhardware_legacy/include -I $SDK_ROOT/hardware/ril/include -I $SDK_ROOT/dalvik/libnativehelper/include -I $SDK_ROOT/frameworks/base/include -I $SDK_ROOT/frameworks/base/opengl/include -I $SDK_ROOT/external/skia/include -I $SDK_ROOT/out/target/proct/generic/obj/include -I $SDK_ROOT/bionic/libc/arch-arm/include -I $SDK_ROOT/bionic/libc/include -I $SDK_ROOT/bionic/libstdc++/include -I $SDK_ROOT/bionic/libc/kernel/common -I $SDK_ROOT/bionic/libc/kernel/arch-arm -I $SDK_ROOT/bionic/libm/include -I $SDK_ROOT/bionic/libm/include/arch/arm -I $SDK_ROOT/bionic/libthread_db/include -I $SDK_ROOT/bionic/libc/kernel/common -I $SDK_ROOT/bionic/libc/kernel/arch-arm -I $SDK_ROOT/system/core/libcutils -I $SDK_ROOT/out/target/proct/generic/obj/STATIC_LIBRARIES/libcutils_intermediates -I $SDK_ROOT/out/target/proct/generic/obj/STATIC_LIBRARIES/libwebcore_intermediates -I $SDK_ROOT/system/core/include/arch/linux-arm/ -include $SDK_ROOT/system/core/include/arch/linux-arm/AndroidConfig.h" \ CFLAGS="-nostdlib -fno-exceptions -fpic -ffunction-sections -funwind-tables -fstack-protector -fno-short-enums -Wno-multichar -msoft-float -march=armv5te -mtune=xscale -D__ARM_ARCH_5__ -D__ARM_ARCH_5T__ -D__ARM_ARCH_5E__ -D__ARM_ARCH_5TE__ -mthumb-interwork -DANDROID -fmessage-length=0 -W -Wall -Wno-unused -Winit-self -Wpointer-arith -Werror=return-type -Werror=non-virtual-dtor -Werror=address -Werror=sequence-point -DSK_RELEASE -DNDEBUG -g -Wstrict-aliasing=2 -finline-functions -fno-inline-functions-called-once -fgcse-after-reload -frerun-cse-after-loop -frename-registers -DNDEBUG -UDEBUG -mthumb -Os -fomit-frame-pointer -fno-strict-aliasing -finline-limit=64" \ LIBS="-L$SDK_ROOT/out/target/proct/generic/obj/lib -L$SDK_ROOT/out/target/proct/generic/obj/STATIC_LIBRARIES/libcutils_intermediates/libcutils.a -lc -lm -ldl $SDK_ROOT/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/../lib/gcc/arm-eabi/4.4.0/interwork/libgcc.a"
進入到curl的根目錄，運行這個腳本：
1.2 Make
進入curl的根目錄，運行make curl命令：
1.3 參數配置
您可能會看到參數配置是復雜的。如何設置呢？你應該閱讀curl/ Android.mk的注釋。
2 iOS
我改變了參數的配置，所以配置命令是：
./configure –disable-shared –host=arm-apple-darwin10
3.視窗
打開的vc6curl.dsw，並選擇「DLL Release」來編譯。您會在CURL_ROOT\lib\DLL-Release
發現libcurl.dll和libcurl_imp.lib。
4.關於頭文件
curl/include的頭文件，只在成功配置後使用，頭文件在不同的平台上是不同的。
D. 如何建立android的C/C++交叉編譯環境
因此，構建android上C/C++的交叉編譯環境也就成為了一個很大的需求。特別是對於已經取得root許可權的機器，如果能直接運行按需編譯的二進制文件，那麼將可以做很多有意義和有趣的事情。 很不幸，Google沒有直接給出如何建立這個交叉編譯環境，但是我們可以藉助Google提供的強大的NDK (Native Development Tools)來達到這一目的。NDK的本來目標是編譯得到.so動態鏈接庫文件，然後通過JNI提供給上層的Java調用，從而實現C/C++程序的簡易遷移。而編譯.so和編譯成二進制可執行文件的過程是完全一樣的，這就給了我們可以發揮的空間。 有兩種方式獲取交叉編譯所需的工具鏈：git下prebuilt這個project或者直接去下載NDK，我這里arm-eabi的版本是最新的4.4.0。1 git clone git://android.git.kernel.org/platform/prebuilt.git 然後創建一個helloworld.c文件。1 2 3 4 5 6 //// root@delleon:~/android/myapp# cat helloworld.c#include int main(){printf("HelloWorld!n");return0;} 接下來創建Makefile文件。注意修改其中的NDK_DIR和SDKTOOL為自己的目錄，修改APP為自己的待編譯程序主文件名。另外注意自己的arm-eabi的版本，若有變化則也需要修改。1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 #### root@delleon:~/android/myapp# cat Makefile APP=helloworld NDK_DIR := ~/android/android-ndk-r4 NDK_HOST := linux-x86 SDKTOOL := ~/android/android-sdk-linux_86/tools TOOLCHAIN_PREFIX :=$(NDK_DIR)/build/prebuilt/$(NDK_HOST)/arm-eabi-4.4.0/bin/arm-eabi- CC :=$(TOOLCHAIN_PREFIX)gcc CPP :=$(TOOLCHAIN_PREFIX)g++ LD :=$(CC) COMMON_FLAGS :=-mandroid -ffunction-sections -fdata-sections -Os -g --sysroot=$(NDK_DIR)/build/platforms/android-5/arch-arm -fPIC -fvisibility=hidden -D__NEW__ CFLAGS :=$(COMMON_FLAGS) CFLAGS +=-D__ARM_ARCH_5__ -D__ARM_ARCH_5T__ -D__ARM_ARCH_5E__ -D__ARM_ARCH_5TE__ -DANDROID -DSK_RELEASE -DNDEBUG CFLAGS +=-UDEBUG -march=armv5te -mtune=xscale -msoft-float -mthumb-interwork -fpic -ffunction-sections -funwind-tables -fstack-protector -fmessage-length=0-Bdynamic CPPFLAGS :=$(COMMON_FLAGS)-fno-rtti -fno-exceptions -fvisibility-inlines-hidden LDFLAGS +=--sysroot=$(NDK_DIR)/build/platforms/android-5/arch-arm LDFLAGS +=-Bdynamic -Wl,-dynamic-linker,/system/bin/linker -Wl,--gc-sections -Wl,-z,noreloc LDFLAGS +=-L$(NDK_DIR)/build/prebuilt/$(NDK_HOST)/arm-eabi-4.4.0/lib/gcc/arm-eabi/4.4.0 LDFLAGS +=-L$(NDK_DIR)/build/prebuilt/$(NDK_HOST)/arm-eabi-4.4.0/lib/gcc LDFLAGS +=-L$(NDK_DIR)/build/prebuilt/$(NDK_HOST)/arm-eabi-4.4.0/arm-eabi/lib LDFLAGS +=-nostdlib -lc -llog -lgcc --no-undefined -z $(NDK_DIR)/build/platforms/android-5/arch-arm/usr/lib/crtbegin_dynamic.o $(NDK_DIR)/build/platforms/android-5/arch-arm/usr/lib/crtend_android.o OBJS +=$(APP).o all:$(APP) $(APP):$(OBJS)$(LD)$(LDFLAGS)-o $@$^ %.o:%.c $(CC)-c $(CFLAGS)$
E. 在linux apache php環境下,如何配置php的openssl模塊各位高手快顯顯神通吧
回答不了你。只是說說我的經驗，看看有沒有幫助。openssl編譯有些麻煩。最好用別人編譯好的，直接安裝。不管是centos, ubuntu, 還是freebsd都可以找到別人編譯好的openssl庫。安裝上就可以了。然後是apache2, 也可找支持openssl的版本，直接安裝。自己編譯也可以，不過相當的麻煩。這樣其實已經支持SSL了。
php不需要支持openssl，apache+php，只要apache支持了。打開43埠，在虛擬主機里設置43的虛擬主機就可以支持ssl。在虛擬主機里配置上php的連接方式。
tls是openssl中加密協議的一種。應該至少還有另外的兩種。
F. 如何利用GCC編譯選項檢測棧溢出
gcc的一個編譯選項：-fstack-protector，以下是關於這個選項的描述： -fstack-protector 啟用該選項後編譯器會產生額外的代碼來檢測緩沖區溢出，例如棧溢出攻擊。這是通過在有缺陷的函數中添加一個保護變數來實現的。這包括會調用到alloca的函數
G. 如何利用gcc編譯選項檢測函數參數個數
gcc的一個編譯選項：-fstack-protector，以下是關於這個選項的描述： -fstack-protector 啟用該選項後編譯器會產生額外的代碼來檢測緩沖區溢出，例如棧溢出攻擊。這是通過在有缺陷的函數中添加一個保護變數來實現的。這包括會調用到alloca的函數.
H. 如何使用自己的makefile編譯android ndk項目
android ndk提供了一套自己的makefile管理方式，要將源碼項目移植到android平台，需要按照android的makefile規則編寫makefile，還要按android的規則部署源碼目錄，對一個有自己的makefile管理方法的大型項目來說，只是做一下makefile遷移工作就是一件很麻煩的事。
其實android ndk上的編譯說到底也就是交叉編譯，只要配置好交叉編譯工具鏈，使用原有的makefile也是可以編譯出在android運行的c、c++程序的。
以android-ndk-r4-crystax的ndk版本為例：
編譯器路徑 android-ndk-r4-crystax/build/prebuilt/linux-x86/arm-eabi-4.4.0/bin
名稱前綴 arm-eabi-
頭文件目錄 android-ndk-r4-crystax/build/platforms/android-3/arch-arm/usr/include
庫文件目錄 android-ndk-r4-crystax/build/platforms/android-3/arch-arm/usr/lib
你可以試一下上面的配置，如果編譯鏈接都沒有問題，可以adb push到android設備上運行看看，什麼結果？
有點崩潰，根本運行不起來，你也許想試試看android自帶的ndk例子，確實是能夠運行的，問題在哪兒呢？
只是正確配置了編譯器、頭文件、庫文件還不夠，還需要配置編譯、鏈接的參數，android例子中編譯鏈接的參數是什麼呢？你也許想深究一下android的makefile，可是不久你會發現那是更崩潰的事情，裡面用了很多的make腳本函數。其實android的makefile是可以把執行的詳細命令輸出來的，只要make的時候加上V=1即可。可以看到確實帶了很多參數
編譯參數：
-fpic
-mthumb-interwork
-ffunction-sections
-funwind-tables
-fstack-protector
-fno-short-enums
-Wno-psabi
-march=armv5te
-mtune=xscale
-msoft-float
-mthumb
-fomit-frame-pointer
-fno-strict-aliasing
-finline-limit=64
-Wa,--noexecstack
-D__ARM_ARCH_5__
-D__ARM_ARCH_5T__
-D__ARM_ARCH_5E__
-D__ARM_ARCH_5TE__
-DANDROID
鏈接參數：
-nostdlib
-Bdynamic
-Wl,-dynamic-linker,/system/bin/linker
-Wl,--gc-sections
-Wl,-z,noreloc
-Wl,--no-undefined
-Wl,-z,noexecstack
-L$(PLATFORM_LIBRARY_DIRECTORYS)
crtbegin_static.o
crtend_android.o
這其中鏈接參數中的-Wl,-dynamic-linker,/system/bin/linker、crtbegin_static.o、crtend_android.o是最關鍵的，android使用了自己的進程載入器，並且自定義了c運行時的啟動結束。難怪先前編譯的進程啟動不了。
I. [gdb]函數堆棧亂掉的解決辦法 [轉]
程序core掉,要去debug,但是函數堆棧亂掉了,很惡心.....經過Google/wiki一番,找到兩種解決辦法.
x86ManualBacktrace
This tutorial will show you how to manually rebuild a backtrace with GDB on x86 using the stack frame pointer and current instruction pointer.
Consider the following gdb backtrace:
It's pretty clear that this is corrupted, evidence the following field:
Get the register information for the process:
On x86:
Stack Frame Layout for x86:
Color Key:blue
Using the current stack frame address from %ebp mp the stack above it:
Using this stack mp we know that the stack frame address in the %ebp register is the stack frame for the current instruction in the %eip register (unless this was a leaf function which didn't stack a frame but that's irrelevant for this discussion). Using the %ebp and %eip registers as a starting point we can build the first line in our backtrace rebuild:
When program control branches to a new function a stack frame is stacked and the callee function's last address is stored at the new frame's address %ebp + 4 (i.e. the last memory address in the callee's stack frame which is +4 from the current stack frame at %ebp). In order to get the caller's stack frame and instruction pointer just look at %ebp and %ebp+4:
In the stack find the memory at the stack frame in %ebp and the one at %ebp+4 (which will hold the callee's instruction pointer).
So using the address at 0xbf9ef358 and 0xbf9ef35c which is 0xbf9ef388 and 0x00d94cf7 continue to build our list:
Continue by looking at the next stack frame address 0xbf9ef388:
Keep doing this until we have a full back trace. You'll know you've reached the bottom of the stack when the previous stack frame pointer is 0x00000000.
Here's a complete manually rebuilt stack frame:
amd64下面,無非就是寄存器變成rbp,字長增加了一倍.當然這邊選擇了手動尋找函數返回地址,然後info symbol列印出函數名,其實還可以通過gdb格式化來直接列印函數名:
gdb>x/128agrbp內的內容
所以手動還原的辦法就變得很簡單:
gdb>info reg rbp*x86換成info reg ebp
gdb>x/128ag rbp內的內容 *x86換成 x/128aw ebp的內容
這樣就能看到函數棧.如果你想解析參數是啥,也是可以的,只是比較麻煩,苦力活兒....想解析參數,就要知道棧的布局,可以參考這篇文章: http://blog.csdn.net/liigo/archive/2006/12/23/1456938.aspx
昨天和 海洋 一塊研究了下函數調用棧，順便寫兩句。不足或錯誤之處請包涵！
理解調用棧最重要的兩點是：棧的結構，EBP寄存器的作用。
首先要認識到這樣兩個事實：
1、一個函數調用動作可分解為：零到多個PUSH指令（用於參數入棧），一個CALL指令。CALL指令內部其實還暗含了一個將返回地址（即CALL指令下一條指令的地址）壓棧的動作。
2、幾乎所有本地編譯器都會在每個函數體之前插入類似如下指令：PUSH EBP; MOV EBP ESP;
即，在程序執行到一個函數的真正函數體時，已經有以下數據順序入棧：參數，返回地址，EBP。由此得到類似如下的棧結構（參數入棧順序跟調用方式有關，這里以 C語言 默認的CDECL為例）：
「PUSH EBP」「MOV EBP ESP」這兩條指令實在大有深意：首先將EBP入棧，然後將棧頂指針ESP賦值給EBP。「MOV EBP ESP」這條指令表面上看是用ESP把EBP原來的值覆蓋了，其實不然——因為給EBP賦值之前，原EBP值已經被壓棧（位於棧頂），而新的EBP又恰恰指向棧頂。
此時EBP寄存器就已經處於一個非常重要的地位，該寄存器中存儲著棧中的一個地址（原EBP入棧後的棧頂），從該地址為基準，向上（棧底方向）能獲取返回地址、參數值，向下（棧頂方向）能獲取函數局部變數值，而該地址處又存儲著上一層函數調用時的EBP值！
一般而言，ss:[ebp+4]處為返回地址，ss:[ebp+8]處為第一個參數值（最後一個入棧的參數值，此處假設其佔用4位元組內存），ss:[ebp-4]處為第一個局部變數，ss:[ebp]處為上一層EBP值。
由於EBP中的地址處總是「上一層函數調用時的EBP值」，而在每一層函數調用中，都能通過當時的EBP值「向上（棧底方向）能獲取返回地址、參數值，向下（棧頂方向）能獲取函數局部變數值」。如此形成遞歸，直至到達棧底。這就是函數調用棧。
編譯器對EBP的使用實在太精妙了。
從當前EBP出發，逐層向上找到所有的EBP是非常容易的：
這個辦法比較簡單,很容易實踐,但是有一個前提,如果棧的內容被沖刷干凈了,你連毛都看不到(事實就是這樣).所以你需要開始棧保護...至少你還能找到棧頂的函數...
gcc有參數: -fstack-protector 和 -fstack-protector-all,強烈建議開啟....
**********************************************************************/
用列印方法調試
在客戶項目那裡混了半年，發現Top的客戶確實是比我們牛逼。先說說調試的方法。
客戶那邊不依賴於GDB調試，因為他們可能覺得GDB依賴於系統 實現，不利於移植吧，所以客戶的程序完全是依賴於列印調試的。這點很佩服他們的軟體規劃能力和項目管理，實現能力。說老實話，如果換了一家中國公司，每人 一個調試方法，要follow 一個rule是很不容易的。
完善的調試菜單。調試菜單並不難實現，只是一個列印和字元接受的函數。在其中控制是開放某些列印信息。
在每個模塊中加上仔細規劃列印輸出，根據需求分成不同的基本。最好情況是在最高列印級別中可以可以發現所有的問題。列印級別可以很方便的動態控制。
函數調用LOG
如果能定位發生問題的模塊，可以在該模塊的在每個函數的調用入口加上列印一個函數名字+Enter，在返回處加上一個函數名字+Exit。對於每個模塊用一個列印開關控制是否列印Trace信息。在調試菜單中控制這個列印開關。
如果懶得加列印語句，可以利用gcc 的-finstrument-functions 選項來快速的加入調試信息。-finstrumnet-function會是的編譯器在函數調用的開始和退出處調用
可以利用這兩個函數來跟蹤函數調用的過程。
在 實現這兩個函數時要加入 attribute ((no_instrument_function));以避免編譯器再調用這兩個函數的時候也調用__cyg_profile_func_enter 和 __cyg_profile_func_exit 而造成循環調用。
可以用dladdr（）來獲得this_fn的文件和函數名。code如下：
// 由於dladdr是GNU擴展，不是dl的標准函數，因此在這句話必須加在文件的開始處
關於列印堆棧。可以用
該方法需要編譯器支持。
但是需要在編譯的時候加上-rdynamic 否則只能輸出在內存中的絕對地址。
在沒有-rdynamic的時候，關於如何找到動態庫的運行時地址還需要研究。
可以在系統運行的時候發送SIGSEGV給應用程序，產生當前進程的Coremp來獲取動態庫中函數的運行是地址。
用GDB獲取backtrace的方法（在有-g選項的時候可以看到，不需要-rdynamic）:
list <*address>
在沒有-g的時候，又該如何呢？
J. 如何利用GCC編譯選項檢測棧溢出
gcc的一個編譯選項：-fstack-protector，以下是關於這個選項的描述：
-fstack-protector
啟用該選項後編譯器會產生額外的代碼來檢測緩沖區溢出，例如棧溢出攻擊。這是通過在有缺陷的函數中添加一個保護變數來實現的。這包括會調用到alloca的函數，以及具有超過8個位元組緩沖區的函數。當執行到這樣的函數時，保護變數會得到初始化，而函數退出時會檢測保護變數。如果檢測失敗，會輸出一個錯誤信息並退出程序。
！注意：在Ubuntu 6.10以及之後的版本中，如果編譯時沒有指定-fno-fstack-protector, -nostdlib或者-ffreestanding選項的話，那麼這個選項對於C，C++，ObjC，ObjC++語言默認是啟用的。