gpt4 book ai didi

debugging - strace 可以告诉我在我的代码中调用系统调用的位置吗?

转载 作者:行者123 更新时间:2023-12-05 00:42:08 25 4
gpt4 key购买 nike

我正在尝试调试 ngspice 的原因在运行模拟时将烦人的换行符打印到 stderr。我试图在可追溯到 1993 年的 2400 个源文件之一中找到它,但这并不像听起来那么容易!然而,这确实意味着我有一个嵌入了所有调试信息的二进制文件。

我的第一个想法是 strace可以帮助我找到我认为有问题的调用并将其追溯到源代码。例如,我很确定这是有问题的系统调用:

   brk(0x55d1a84e9000)                     = 0x55d1a84e9000                                                                                                                                         
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=0, tv_nsec=61462905}) = 0
>> write(2, "\n", 1) = 1
getrusage(RUSAGE_SELF, {ru_utime={tv_sec=0, tv_usec=26269}, ru_stime={tv_sec=0, tv_usec=35243}, ...}) = 0
openat(AT_FDCWD, "/proc/self/statm", O_RDONLY) = 3

我曾希望,如果我跟踪一个包含调试信息的可执行文件,strace 会显示源代码中的位置,但这并不是自动发生的,而且手册有点让人不知所措。

我在手册中找到了一个名为 Tracing 的部分,但找不到任何具体内容。

strace 是否可以,如果可以:如何?如果没有,您还有其他建议吗?

最佳答案

事后看来很明显,但一个非常有用的标志是 -k。从手册页:

-k Print the execution stack trace of the traced processes after each system call.

这需要一个带有调试信息的二进制文件,它会变得非常嘈杂,但结合一个简单的过滤器(在本例中为 -e write),您最终会得到如下所示的内容:

write(2, "\n", 1
) = 1
> /lib/x86_64-linux-gnu/libc-2.28.so(__write+0x14) [0xea504]
> /lib/x86_64-linux-gnu/libc-2.28.so(_IO_file_write+0x2d) [0x7b3bd]
> /lib/x86_64-linux-gnu/libc-2.28.so(_IO_file_setbuf+0xef) [0x7a75f]
> /lib/x86_64-linux-gnu/libc-2.28.so(_IO_do_write+0x19) [0x7c509]
> /lib/x86_64-linux-gnu/libc-2.28.so(_IO_file_overflow+0x103) [0x7c8f3]
> /home/pipe/src/ngspice/debug/src/ngspice(OUTendPlot+0x1ae) [0xd7643]
> /home/pipe/src/ngspice/debug/src/ngspice(DCop+0x167) [0x4cd788]
> /home/pipe/src/ngspice/debug/src/ngspice(CKTdoJob+0x428) [0x4c70dd]
> /home/pipe/src/ngspice/debug/src/ngspice(if_run+0x3b9) [0xe5d3e]
> /home/pipe/src/ngspice/debug/src/ngspice(dosim+0x428) [0xe02ee]

在跟踪一些函数内联优化之后,我最终可以找到正确的位置。

关于debugging - strace 可以告诉我在我的代码中调用系统调用的位置吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/57468021/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com