深入探究Linux调试技术:LinuxDebug(linuxdebug)

Linux Debug是指在Linux系统中对程序进行调试的技术。在Linux发行版中,包含了多种用于调试的工具,例如GDB、strace、perf等。这些工具可以帮助开发者查找程序中的错误,优化程序性能,提高程序的可靠性。

成都创新互联是一家专业提供乌什企业网站建设,专注与网站设计、做网站html5、小程序制作等业务。10年已为乌什众多企业、政府机构等服务。创新互联专业网络公司优惠进行中。

本文将介绍Linux Debug技术的原理和使用方法,帮助开发者了解如何使用这些工具进行程序调试。

一、GDB调试工具

GDB是Linux中最常用的调试工具之一,它可以在运行程序时跟踪程序的状态,查找程序中的错误。

1.基本使用方法

使用GDB需要先编译程序时启用调试选项(-g),然后在运行程序时加上-g选项,这样GDB就可以对程序进行跟踪。使用GDB启动程序后,可以通过命令行输入不同的命令来查看程序的状态,例如:

(1)break:设置程序中断点

(2)run:启动程序

(3)step:单步执行程序

(4)print:查看变量的值

GDB的命令行操作比较繁琐,但它可以提供各种深入的调试功能,非常适合用于排查程序问题。

2.高级调试功能

除了基本的命令行操作外,GDB还提供了一些高级调试功能,例如:

(1)远程调试:GDB支持通过SSH连接到远程机器上,从而在远程机器上进行调试。使用这个功能可以方便地对分布式系统进行调试。

(2)断点恢复:GDB支持在程序崩溃时进行断点恢复,这样可以避免在程序崩溃后需要重新设置断点。

(3)条件断点:GDB支持在设置断点时加上条件,只有满足条件时才会产生中断。

二、strace系统调用跟踪工具

strace是一种能够跟踪程序所调用的系统调用的工具,通过跟踪系统调用,可以了解程序的运行情况,找到程序的问题。

1.基本使用方法

使用strace调试程序很简单,只需要在运行程序时加上strace的命令即可,例如:strace -o log.txt ./helloworld。这样运行程序时就会把系统调用信息输出到log.txt文件中。

2.工具使用注意事项

strace的输出信息比较冗长,需要进行过滤和分析。用户可以使用grep命令等对输出信息进行过滤,找到所需信息。

三、perf性能压测工具

perf是一种性能压测工具,可以帮助开发者了解程序的瓶颈所在,进而对程序进行优化。

1.基本使用方法

使用perf进行性能压测很简单,只需要在运行程序时加上perf的命令即可,例如:perf stat ./helloworld。这样运行程序时就会输出程序的性能信息。

2.工具使用注意事项

perf输出的信息也很冗长,需要进行分析和过滤。开发者可以根据perf的分析结果对程序进行优化,提高程序的性能。

本文介绍了Linux Debug技术的三种常用工具:GDB、strace、perf。通过这些工具的使用,开发者可以更加方便地查找程序中的错误,优化程序性能,提高程序的可靠性。

需要注意的是,在使用这些工具时需要对Linux系统和程序的运行机制有一定的了解,只有这样才能更加高效地使用这些工具。希望本文对广大开发者有所帮助。

成都网站建设公司-创新互联,建站经验丰富以策略为先导10多年以来专注数字化网站建设,提供企业网站建设,高端网站设计,响应式网站制作,设计师量身打造品牌风格,热线:028-86922220

在linux下编译软件和第三方库时不分debug和release吗

Linux系统编译软件是有debug版和release版本的区分。Linux下在开发软件的过程中,会编译成debug版的,用于程序调试。以gcc/g++编译命令来说,在编译产生.o文件时(必须是产生.o文件的那一步才能编译成调试版),加入-g编译选项,编译出来的就是debug版,这个版本可以用gdb调试。

而如果软件开发完成需要发布的时候,就需要在编译时加上-O选项(不能加-g选项了),表示对代码进行编译优化,这时编译出来的软件就相当于是release版本了。

如何在Android 或Linux 下,做Suspend /Resume 的Debug

在Linux或Android下,做power management 的调适时,常遇到没有足够的information,可以做为debug时的依据和参考

我们整理了几个常用的参数或Command,可供设计者,得到足够的Informaiton 做Suspend / Resume的function Debug。

加boot 参数 no_console_suspend

基本上我们常常使用console做为suspend function的debug的Information source,但原始的source code在suspend过程中,会将console关掉。所以我们扰锋看到一定程度後就再也看不到message了。

但是我们并不知道在Suspend的过程中老李配,系统到底发生了什麼事,可能造成无法suspend。

为此,我们就会在kernel 启动参数中加上no_console_suspend这个参数。在AM/DM37x APM中是修改boot.scr档案参数

#!/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 参数後就好了

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 参数的所在档案即可(在U-boot Source code中)

这个是基本的参数,所以在Android或Linux上都可以使用。 kernel把console suspend掉侍指以後, 不管里面出了什麼事情, 在Console上都看不到。 而使用这个参数後,大部分在suspend/resume时候的死机都可以通过Console看到kernel Panic的信息, 这样我们才会知道是哪里出了问题。 因为有的时候resume出错, 或者suspend到很後面出错的console不加这个参数都看不到。

但这个参数在TI OMAP3/OMAP4/AM37x/DM37x有可能造成有时Suspend 完当掉或是resume 失败的问题,假如已经抓到问题在那的时候,您就可以将这个参数Disable,不然很可能就会Debug不下去。

initcall_debug

这个同样kernel参数,使用的时机是,当我们不知道是那个driver在suspend/resume过程中出错的时候,可以使用这个参数来找出问题所在。在下完这个参数後,Kernel在suspend时,会将每个driver或task的状况report出来。我们可以藉由这些information,Check 在suspend时,每个task和driver是否已经完成进suspend 的相关准备工作…

打开这个参数的方法有二种

一种是在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的启动参数下,就可以了。

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’

同样的,这个参数也有可能造成AM37x/DM37x/OMAP4 APM发生进suspend当掉的问题。所以一旦知道问题所在,麻烦请将这个参数Disable掉。

suspend_test

这个方法可以用rtc这种软件的方式来做循环的suspend/resume, 尽管对於Android这样并不是很足够, (还要再模拟一个POWER_KEY上去才够), 但是对於测试Driver的稳定性, 还是有一定用处的。不要认为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

这样, 它就会循环休眠和唤醒了。

wakelock

Android和Linux在Power Management相关的更大的就是wakelock机制的有无。Android有时候会碰到suspend进不去,或者suspend到最後又莫名奇妙的wake up的问题。这些都有可能是wakelock引起的,或者说是wakelock的使用者引起的。怎麼fine tune呢,使用Console在Android 系统下设定:

echo 15 > /sys/module/wakelock/parameters/debug_mask

echo 15 > /sys/module/userwakelock/parameters/debug_mask

15是代表16进制的F, 在wakelock里面就是把所有的debug信息打开, 起码现在是这样设定的。如果以後不够用了,可能就会改成255.

这样你能看到kernel和frameworks层对於wakelock的操作、申请及释放。这样看申请和释放成对否就可以了。

注意: wakelock有一种是timeout的,就是说多少毫秒以後,会自动释放,对於这些wakelock,申请和释放可能是不成对的。

power.0

有时看到系统suspend到了最後, 然後遇到power.0後suspend失败,然後整个系统又resume回来。这个是android专有的,因为power.0是android注册到suspend最後的一个行程, 它会在CPU进入suspend之前检查一下有没有wakelock存在, 如果这时候还有没有释放的wakelock, 那麼它会return -EBUSY然後导致整个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有相关的机制叫earlysuspend, 同样可以打开debug message,用来做Android earlysuspend debug之用:

echo 15 > /sys/module/earlysuspend/parameters/debug_mask

来把相关的debug信息印出来, 例如那个earlysuspend要被call之类的。

suspend/resume 时间 fine tune

有的时候你要调试suspend/resume的时间太慢的问题。 一种方法是用initcall_debug, 然後把printk的时间戳打上, 然後看那个process最慢,再来Check原因是什麼

我有一个patch,专门用来调试这个问题的,但是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打出来,然後你去干掉它。 。

关于linuxdebug的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。

成都创新互联科技有限公司,经过多年的不懈努力,公司现已经成为一家专业从事IT产品开发和营销公司。广泛应用于计算机网络、设计、SEO优化、关键词排名等多种行业!

当前题目:深入探究Linux调试技术:LinuxDebug(linuxdebug)
地址分享:http://www.36103.cn/qtweb/news34/6734.html

网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联