正如标题上说的,在我的系统中,ltrace不能正常工作。在大多数情况下,它没有显示输出,例如
$ltrace ls
[usual ls output]
+++ exited (status 0) +++
$gcc hello.c
$ltrace ./a.out
Hello world!
+++ exited (status 0) +++
我使用的是最新的ltrace版本(来自package 0.7.3-5.1ubuntu4
),我甚至尝试从源代码重新编译,没有差别。我正在使用Ubuntu 16.10
,内核4.8.0-42-generic
。gcc版本是6.2.0
。
奇怪的是,从互联网下载的二进制文件似乎工作正常,正确地显示了库调用。
我遗漏了什么?有人能复制这个问题吗?
发布于 2017-05-31 22:14:18
这可能与使用-z now
编译的二进制文件有关。我创建了一个快速测试程序(我使用的是Ubuntu16.04):
int main() {
write(0, "hello\n", 6);
return 0;
}
如果我用gcc -O2 test.c -o test
编译它,那么ltrace就能工作:
$ ltrace ./test
__libc_start_main(0x400430, 1, 0x7ffc12326528, 0x400550 <unfinished ...>
write(0, "hello\n", 6hello
) = 6
+++ exited (status 0) +++
但是,当我使用gcc -O2 test.c -Wl,-z,relro -Wl,-z,now -o test2
编译时,它不会:
$ ltrace ./test2
hello
+++ exited (status 0) +++
您可以使用Ubuntu上的scanelf
包中的pax-utils
来检查二进制文件是否像这样编译:
$ scanelf -a test*
TYPE PAX PERM ENDIAN STK/REL/PTL TEXTREL RPATH BIND FILE
ET_EXEC PeMRxS 0775 LE RW- R-- RW- - - LAZY test
ET_EXEC PeMRxS 0775 LE RW- R-- RW- - - NOW test2
注意,LAZY
(ltrace )与NOW
(ltrace )不同。
这里有一些更多的讨论(但没有决议):
发布于 2021-05-08 16:50:08
简单的回答是,由于所跟踪的二进制文件类型和位置独立于可执行的对象,ltrace
的行为不像预期的那样。如果正在跟踪的二进制文件具有ET_EXEC
对象文件类型,并且没有独立于位置的可执行文件,那么ltrace
将能够拦截和记录动态库调用。
对象文件类型(ET_EXEC
、ET_DYN
等)对于二进制文件,请参考精灵头 (0x10偏移量)。
为了验证这一点,我将使用与前面的答案相同的test.c
程序:
#include <unistd.h>
int main() {
write(0, "hello\n", 6);
return 0;
}
我的系统根据/etc/os-release
NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
默认gcc -v
(版本和配置):
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.3.0-17ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-9-HskZEa/gcc-9-9.3.0/debian/tmp-nvptx/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)
现在用gcc test.c -o test
编译,我们有:
$ ltrace ./test
hello
+++ exited (status 0) +++
用readelf -h ./test | grep Type
检查二进制文件类型
Type: DYN (Shared object file)
用hardening-check ./test | grep Position
检查位置独立执行
Position Independent Executable: yes
然而,使用gcc -no-pie test.c -o test
编译,我们有:
$ ltrace ./test
write(0, "hello\n", 6hello
) = 6
+++ exited (status 0) +++
用readelf -h ./test | grep Type
检查二进制文件类型
Type: EXEC (Executable file)
用hardening-check ./test | grep Position
检查位置独立执行
Position Independent Executable: no, normal executable!
希望这有助于澄清ltrace
的行为及其与对象文件类型和位置无关的二进制文件可执行性之间的关系。
https://stackoverflow.com/questions/43213505
复制相似问题