建站
咨詢
售后
建站咨詢
新聞中心
Linux Debug是指在Linux系統(tǒng)中對程序進行調(diào)試的技術(shù)。在Linux發(fā)行版中，包含了多種用于調(diào)試的工具，例如GDB、strace、perf等。這些工具可以幫助開發(fā)者查找程序中的錯誤，優(yōu)化程序性能，提高程序的可靠性。
成都創(chuàng)新互聯(lián)是一家專業(yè)提供烏什企業(yè)網(wǎng)站建設(shè),專注與網(wǎng)站設(shè)計、做網(wǎng)站、html5、小程序制作等業(yè)務(wù)。10年已為烏什眾多企業(yè)、政府機構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)絡(luò)公司優(yōu)惠進行中。
本文將介紹Linux Debug技術(shù)的原理和使用方法，幫助開發(fā)者了解如何使用這些工具進行程序調(diào)試。
一、GDB調(diào)試工具
GDB是Linux中最常用的調(diào)試工具之一，它可以在運行程序時跟蹤程序的狀態(tài)，查找程序中的錯誤。
1.基本使用方法
使用GDB需要先編譯程序時啟用調(diào)試選項（-g），然后在運行程序時加上-g選項，這樣GDB就可以對程序進行跟蹤。使用GDB啟動程序后，可以通過命令行輸入不同的命令來查看程序的狀態(tài)，例如：
（1）break：設(shè)置程序中斷點
（2）run：啟動程序
（3）step：單步執(zhí)行程序
（4）print：查看變量的值
GDB的命令行操作比較繁瑣，但它可以提供各種深入的調(diào)試功能，非常適合用于排查程序問題。
2.高級調(diào)試功能
除了基本的命令行操作外，GDB還提供了一些高級調(diào)試功能，例如：
（1）遠程調(diào)試：GDB支持通過SSH連接到遠程機器上，從而在遠程機器上進行調(diào)試。使用這個功能可以方便地對分布式系統(tǒng)進行調(diào)試。
（2）斷點恢復(fù)：GDB支持在程序崩潰時進行斷點恢復(fù)，這樣可以避免在程序崩潰后需要重新設(shè)置斷點。
（3）條件斷點：GDB支持在設(shè)置斷點時加上條件，只有滿足條件時才會產(chǎn)生中斷。
二、strace系統(tǒng)調(diào)用跟蹤工具
strace是一種能夠跟蹤程序所調(diào)用的系統(tǒng)調(diào)用的工具，通過跟蹤系統(tǒng)調(diào)用，可以了解程序的運行情況，找到程序的問題。
1.基本使用方法
使用strace調(diào)試程序很簡單，只需要在運行程序時加上strace的命令即可，例如：strace -o log.txt ./helloworld。這樣運行程序時就會把系統(tǒng)調(diào)用信息輸出到log.txt文件中。
2.工具使用注意事項
strace的輸出信息比較冗長，需要進行過濾和分析。用戶可以使用grep命令等對輸出信息進行過濾，找到所需信息。
三、perf性能壓測工具
perf是一種性能壓測工具，可以幫助開發(fā)者了解程序的瓶頸所在，進而對程序進行優(yōu)化。
1.基本使用方法
使用perf進行性能壓測很簡單，只需要在運行程序時加上perf的命令即可，例如：perf stat ./helloworld。這樣運行程序時就會輸出程序的性能信息。
2.工具使用注意事項
perf輸出的信息也很冗長，需要進行分析和過濾。開發(fā)者可以根據(jù)perf的分析結(jié)果對程序進行優(yōu)化，提高程序的性能。
：
本文介紹了Linux Debug技術(shù)的三種常用工具：GDB、strace、perf。通過這些工具的使用，開發(fā)者可以更加方便地查找程序中的錯誤，優(yōu)化程序性能，提高程序的可靠性。
需要注意的是，在使用這些工具時需要對Linux系統(tǒng)和程序的運行機制有一定的了解，只有這樣才能更加高效地使用這些工具。希望本文對廣大開發(fā)者有所幫助。
成都網(wǎng)站建設(shè)公司-創(chuàng)新互聯(lián),建站經(jīng)驗豐富以策略為先導(dǎo)10多年以來專注數(shù)字化網(wǎng)站建設(shè),提供企業(yè)網(wǎng)站建設(shè),高端網(wǎng)站設(shè)計,響應(yīng)式網(wǎng)站制作,設(shè)計師量身打造品牌風(fēng)格,熱線:028-86922220在linux下編譯軟件和第三方庫時不分debug和release嗎
Linux系統(tǒng)編譯軟件是有debug版和release版本的區(qū)分。Linux下在開發(fā)軟件的過程中，會編譯成debug版的，用于程序調(diào)試。以gcc/g++編譯命令來說，在編譯產(chǎn)生.o文件時（必須是產(chǎn)生.o文件的那一步才能編譯成調(diào)試版），加入-g編譯選項，編譯出來的就是debug版，這個版本可以用gdb調(diào)試。
而如果軟件開發(fā)完成需要發(fā)布的時候，就需要在編譯時加上-O選項（不能加-g選項了），表示對代碼進行編譯優(yōu)化，這時編譯出來的軟件就相當(dāng)于是release版本了。
如何在Android 或Linux 下，做Suspend /Resume 的Debug
在Linux或Android下，做power management 的調(diào)適時，常遇到?jīng)]有足夠的information，可以做為debug時的依據(jù)和參考
我們整理了幾個常用的參數(shù)或Command，可供設(shè)計者，得到足夠的Informaiton 做Suspend / Resume的function Debug。
加boot 參數(shù) no_console_suspend
基本上我們常常使用console做為suspend function的debug的Information source，但原始的source code在suspend過程中，會將console關(guān)掉。所以我們擾鋒看到一定程度後就再也看不到message了。
但是我們并不知道在Suspend的過程中老李配，系統(tǒng)到底發(fā)生了什麼事，可能造成無法suspend。
為此，我們就會在kernel 啟動參數(shù)中加上no_console_suspend這個參數(shù)。在AM/DM37x APM中是修改boot.scr檔案參數(shù)
#!/bin/sh
cat boot.cmd
if fatload mmcuImage
then
echo ***** Kernel: /dev/mmcblk0p1/uImage *****
fi
echo ***** RootFS: /dev/mmcblk0p2 *****
# Pantherboard DVI output
#setenv bootargs ‘console=ttyO2,115200n8 androidboot.console=ttyO2 mem=512M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off omap_vout.vid1_static_vrfb_alloc=y omapdss.def_disp=dvi vram=32M omapfb.mode=dvi:1280x720MR-32 omapfb.vram=0:16M mpurate=1000’
# Pantherboard LCD output
setenv bootargs ‘console=ttyO2,115200n8 androidboot.console=ttyO2 mem=512M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off omap_vout.vid1_static_vrfb_alloc=y omapdss.def_disp=lcd omapfb.mode=lcd:800x480MR-32 vram=8M omapfb.vram=0:8M mpurate=1000’
將no_console_suspend加上去到boot 參數(shù)後就好了
setenv bootargs ‘console=ttyO2,115200n8 androidboot.console=ttyO2 mem=512M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off omap_vout.vid1_static_vrfb_alloc=y omapdss.def_disp=lcd omapfb.mode=lcd:800x480MR-32 vram=8M omapfb.vram=0:8M mpurate=1000 no_console_suspend’
如果是OMAP4 APM的話，請修改Kernel 參數(shù)的所在檔案即可(在U-boot Source code中)
這個是基本的參數(shù)，所以在Android或Linux上都可以使用。 kernel把console suspend掉侍指以後， 不管里面出了什麼事情， 在Console上都看不到。 而使用這個參數(shù)後，大部分在suspend/resume時候的死機都可以通過Console看到kernel Panic的信息， 這樣我們才會知道是哪里出了問題。 因為有的時候resume出錯， 或者suspend到很後面出錯的console不加這個參數(shù)都看不到。
但這個參數(shù)在TI OMAP3/OMAP4/AM37x/DM37x有可能造成有時Suspend 完當(dāng)?shù)艋蚴莚esume 失敗的問題，假如已經(jīng)抓到問題在那的時候，您就可以將這個參數(shù)Disable，不然很可能就會Debug不下去。
initcall_debug
這個同樣kernel參數(shù)，使用的時機是，當(dāng)我們不知道是那個driver在suspend/resume過程中出錯的時候，可以使用這個參數(shù)來找出問題所在。在下完這個參數(shù)後，Kernel在suspend時，會將每個driver或task的狀況report出來。我們可以藉由這些information，Check 在suspend時，每個task和driver是否已經(jīng)完成進suspend 的相關(guān)準備工作…
打開這個參數(shù)的方法有二種
一種是在console下Command，啟動這個function…
echo 1 > /sys/module/kernel/parameters/initcall_debug
echo 9 > /proc/sys/kernel/printk
其中上面的之一條命令是打開initcall_debug， 這個是所有的kernel都會有的。
而第二條命令是要提高kernel message 級別，因為initcall的這些信息都是KERN_DEBUG級別的， 所以需要提高printk的級別才可以看到， 要不然suspend/resume的時候掛了，你就沒有機會看到這些信息了。
另一種啟動方法是寫在kernel的啟動參數(shù)下，就可以了。
setenv bootargs ‘console=ttyO2,115200n8 androidboot.console=ttyO2 mem=512M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off omap_vout.vid1_static_vrfb_alloc=y omapdss.def_disp=lcd omapfb.mode=lcd:800x480MR-32 vram=8M omapfb.vram=0:8M mpurate=1000 initcall_debug no_console_suspend’
同樣的，這個參數(shù)也有可能造成AM37x/DM37x/OMAP4 APM發(fā)生進suspend當(dāng)?shù)舻膯栴}。所以一旦知道問題所在，麻煩請將這個參數(shù)Disable掉。
suspend_test
這個方法可以用rtc這種軟件的方式來做循環(huán)的suspend/resume， 盡管對於Android這樣并不是很足夠， （還要再模擬一個POWER_KEY上去才夠）， 但是對於測試Driver的穩(wěn)定性， 還是有一定用處的。不要認為suspend了幾次可以，那麼就可以通過幾千次的測試。這個suspend是5秒鐘用RTC喚醒，然後回到Android後5秒鐘又會自動睡下去，但是對於通用Linux，你可以寫個script來讓他起來一會再睡下去，或許這個工具比較有用rtcwakeup（google rtcwakeup)。
使用方法：
編譯一個有這個功能的kernel， make menuconfig 以後選上
CONFIG_PM_DEBUG=y
CONFIG_PM_TEST_SUSPEND=y
這兩個選項，燒寫新的kernel，然後打開你需要測試的Device， 比如WIFI，3G
echo “core” > /sys/power/pm_test
echo “mem” > /sys/power/state
這樣， 它就會循環(huán)休眠和喚醒了。
wakelock
Android和Linux在Power Management相關(guān)的更大的就是wakelock機制的有無。Android有時候會碰到suspend進不去，或者suspend到最後又莫名奇妙的wake up的問題。這些都有可能是wakelock引起的，或者說是wakelock的使用者引起的。怎麼fine tune呢，使用Console在Android 系統(tǒng)下設(shè)定：
echo 15 > /sys/module/wakelock/parameters/debug_mask
echo 15 > /sys/module/userwakelock/parameters/debug_mask
15是代表16進制的F， 在wakelock里面就是把所有的debug信息打開， 起碼現(xiàn)在是這樣設(shè)定的。如果以後不夠用了，可能就會改成255.
這樣你能看到kernel和frameworks層對於wakelock的操作、申請及釋放。這樣看申請和釋放成對否就可以了。
注意： wakelock有一種是timeout的，就是說多少毫秒以後，會自動釋放，對於這些wakelock，申請和釋放可能是不成對的。
power.0
有時看到系統(tǒng)suspend到了最後， 然後遇到power.0後suspend失敗，然後整個系統(tǒng)又resume回來。這個是android專有的，因為power.0是android注冊到suspend最後的一個行程， 它會在CPU進入suspend之前檢查一下有沒有wakelock存在， 如果這時候還有沒有釋放的wakelock， 那麼它會return -EBUSY然後導(dǎo)致整個suspend失敗。 Check這個問題的方法就是把上面wakelock的debug信息打開，然後看看是哪個去申請了wakelock，然後Release它。
這個錯誤的錯誤信息大概是這樣的：
pm_noirq_op(): platform_pm_suspend_noirq+0x0/0x38 returns -11
PM: Device power.0 failed to suspend late: error -11
earlysuspend
在android里面中另外一個和Power Management有相關(guān)的機制叫earlysuspend， 同樣可以打開debug message，用來做Android earlysuspend debug之用：
echo 15 > /sys/module/earlysuspend/parameters/debug_mask
來把相關(guān)的debug信息印出來， 例如那個earlysuspend要被call之類的。
suspend/resume 時間 fine tune
有的時候你要調(diào)試suspend/resume的時間太慢的問題。 一種方法是用initcall_debug， 然後把printk的時間戳打上， 然後看那個process最慢，再來Check原因是什麼
我有一個patch，專門用來調(diào)試這個問題的，但是upstream不接受， 說非要用這種折磨人的方法才行， 但是如果你想用可以下下來打上去用一下。
地址在這里:
用法是, 打上這個PATCH以後, 在KERNEL里面選擇上PM_DEBUG， SUSPEND_DEVICE_TIME_DEBUG 這兩個選項。
然後
echo
微秒
> /sys/power/device_suspend_time_threshold
比如
echo> /sys/power/device_suspend_time_threshold
注意這里是微秒哦。 。 。 它會把在suspend/resume的時候慢的那些driver打出來，然後你去干掉它。 。
關(guān)于linuxdebug的介紹到此就結(jié)束了，不知道你從中找到你需要的信息了嗎 ？如果你還想了解更多這方面的信息，記得收藏關(guān)注本站。
成都創(chuàng)新互聯(lián)科技有限公司，經(jīng)過多年的不懈努力，公司現(xiàn)已經(jīng)成為一家專業(yè)從事IT產(chǎn)品開發(fā)和營銷公司。廣泛應(yīng)用于計算機網(wǎng)絡(luò)、設(shè)計、SEO優(yōu)化、關(guān)鍵詞排名等多種行業(yè)！
網(wǎng)頁名稱：深入探究Linux調(diào)試技術(shù)：LinuxDebug(linuxdebug)
分享路徑：http://www.dlmjj.cn/article/dppgghh.html
