运行 ltrace 时无输出

Question

正如标题所示，ltrace 在我的系统上无法正常工作。 在大多数情况下它不显示任何输出，例如

$ltrace ls
[usual ls output]
+++ exited (status 0) +++

$gcc hello.c
$ltrace ./a.out
Hello world!
+++ exited (status 0) +++

我正在使用最新的 ltrace 版本（来自包

0.7.3-5.1ubuntu4

），我什至尝试从源代码重新编译，没有任何区别。 我正在使用 Ubuntu

16.10

，内核

4.8.0-42-generic

。 gcc 版本是

6.2.0

.

奇怪的是，从互联网下载的二进制文件似乎可以工作，正确显示库调用。

我错过了什么？有谁能重现这个问题吗？

Answer 1

这可能与使用

-z now

编译的二进制文件有关。我创建了一个快速测试程序（我使用的是 Ubuntu 16.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 无效）。

这里还有更多讨论（但没有解决方案）：

https://bugzilla.redhat.com/show_bug.cgi?id=1333481

Answer 2

简短的回答是

ltrace

由于被跟踪的二进制文件的对象文件类型和位置独立的可执行文件而没有按预期运行。如果被跟踪的二进制文件具有

ET_EXEC

对象文件类型并且没有位置独立可执行文件，则

ltrace

将能够拦截并记录动态库调用。

有关二进制文件的对象文件类型（

ET_EXEC

、

ET_DYN

等），请参阅ELF标头（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

的行为及其与跟踪的二进制文件的对象文件类型和位置独立可执行文件的关系。

Answer 3

从源代码构建的最新版本 0.7.91 https://gitlab.com/cespedes/ltrace 似乎又可以工作了

删除已安装的0.7.3版本

$ sudo apt remove ltrace

制作并安装

$ git clone https://gitlab.com/cespedes/ltrace.git
$ cd ltrace
$ ./autogen.sh
$ ./configure
$ make
$ sudo make install

测试

$ ltrace --version
ltrace 0.7.91
...

$ ltrace echo
getenv("POSIXLY_CORRECT")                                  = nil
strrchr("echo", '/')                                       = nil
setlocale(LC_ALL, "")                                      = "en_US.UTF-8"
...
fflush(0x7f6afa7426a0)                                     = 0
fclose(0x7f6afa7426a0)                                     = 0
+++ exited (status 0) +++

Answer 4

ltrace 0.7.3 和 ltrace 0.7.91 可以很好地处理使用

-z now

编译的二进制文件，但很难处理

-fno-plt

，因为 ltrace 的工作原理是使用 ptrace 将断点插入到 PLT 存根中。您可以使用

readelf -S

检查是否

-z now

会产生

.plt

段，而

-fno-plt

则不会。有时有效的解决方法是

ltrace -x '*'

或

ltrace -x 'malloc'

，但它也会打印不需要的嵌套库调用。

在这种情况下，更好的工具是 uftrace。你可以像这样使用它：

$ uftrace -a --force ./binary
Hello world!
# DURATION     TID     FUNCTION
 119.352 us [ 55348] | puts("Hello world!") = 13;