我需要调试pthread? [英] What do I need to debug pthreads?

查看:243
本文介绍了我需要调试pthread?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我想在我的自定义linux发行版中调试pthread,但是我缺少一些东西。我的主机是Ubuntu 12.04,我的目标是一个使用crosstool-NG交叉编译器工具集构建的i486定制嵌入式Linux,其余的操作系统使用Buildroot进行。



I将列出事实:




  • 我可以在我的目标上运行多线程应用程序


  • Google Breakpad 在运行多线程时无法创建崩溃报告应用于目标。完全相同的应用程序与完全相同的Breakpad库的构建将成功,当我在我的主机上运行它。


  • GDB无法在我的目标上调试多线程应用程序。




例如

  $。/ gdb -n-exthread apply all backtrace./a.out  - -pid 716 

dlopen在'libthread_db.so.1'上失败 - /lib/libthread_db.so.1:未定义的符号:ps_lgetfpregs
GDB将无法调试pthreads。
GNU gdb 6.8

我不认为ps_lgetfpregs是一个问题,因为这个




  • 我的crosstool构建创建了libthread_db.so文件,并将其放在目标上。


  • 我的crosstool构建为我创建了gdb目标,所以它应该与我在目标上运行的相同的库链接。


  • 如果我在我的主机上运行gdb,对我的测试应用程序,我得到每个正在运行的线程的回溯。




我怀疑Breakpad的问题与GDB的问题有关,但我无法证实这一点。唯一的共同点是缺少多线程调试。



我的主机和目标之间有一些关键的区别,阻止我无法调试目标上的pthreads。



有谁知道是什么?



编辑:


$ b $来自TI的 Denys Dmytriyenko 说:


通常,GDB不是很挑剔,您可以混合和匹配不同的
版本的gdb和gdbserver。但是,不幸的是,如果您需要
调试多线程应用程序,则有一些依赖关系的特定
API ...



例如,这是您可能会看到的消息之一,如果您没有
正确构建GDB的线程支持:



dlopen failed on'libthread_db.so.1 ' - /lib/libthread_db.so.1:
未定义符号:ps_lgetfpregs GDB将无法调试
pthreads。


请注意,这个错误与我得到的错误是一样的,但他没有详细介绍如何正确构建GDB。



GDB常见问题解答说:


(Q)除了发生崩溃之外,GDB没有看到任何线程;
或SIGTRAP在我设置断点时杀死我的程序。



(A)经常在
发生在Linux上,特别是在嵌入式目标上。有两个常见的
原因:




  • 您正在使用glibc,而您已经剥离了libpthread.so.0


  • libpthread.so.0和libthread_db.so.1之间的不匹配




GDB本身没有
不知道如何解码由glibc和
维护的线程控制块,被认为是glibc的私有实现细节。它使用
libthread_db.so.1(glibc的一部分)来帮助它。因此,
libthread_db.so.1和libpthread.so.0必须在版本和
编译标志中匹配。此外,libthread_db.so.1需要某些
非全局符号存在于libpthread.so.0中。



解决方案:使用
strip --strip-debug libpthread.so.0而不是strip libpthread.so.0。


我尝试过一个非剥离的libpthread.so.0,但没有什么区别。我将调查pthread和thread_db之间的任何不匹配。

解决方案

这个:

  dlopen在'libthread_db.so.1'上失败 -  /lib/libthread_db.so.1:未定义的符号:ps_lgetfpregs 
GDB将无法调试pthreads。意味着 libthread_db.so.1

库无法在gdb中找到符号 ps_lgetfpregs



为什么?



因为我使用Crosstoolg-NG与Build a static native gdb并且这将向$ gcc添加 -static 选项。



本地gdb是使用 -rdynamic 选项,并填充 .dynsym 符号表在具有所有符号的ELF文件中,甚至是未使用的符号。 libread_db使用此符号表从gdb中查找 ps_lgetfpregs



-static 从ELF文件中删除 .dynsym 表。



此时有两个选项:


  1. 如果要调试线程,请不要构建静态本地gdb。

  2. 构建静态gdb和静态libthread_db(未测试)

编辑:



顺便说一下,这并不能解释为什么Breakpad无法在我的目标上调试多线程应用程序。


I want to debug pthreads on my custom linux distribution but I am missing something. My host is Ubuntu 12.04, my target is an i486 custom embedded Linux built with a crosstool-NG cross compiler toolset, the rest of the OS is made with Buildroot.

I will list the facts:

  • I can run multi-threaded applications on my target

  • Google Breakpad fails to create a crash report when I run a multi-threaded application on the target. The exact same application with the exact same build of Breakpad libraries will succeed when I run it on my host.

  • GDB fails to debug multithreaded applications on my target.

e.g.

$./gdb -n -ex "thread apply all backtrace" ./a.out --pid 716

dlopen failed on 'libthread_db.so.1' - /lib/libthread_db.so.1: undefined symbol: ps_lgetfpregs
GDB will not be able to debug pthreads.
GNU gdb 6.8

I don't think ps_lgetfpregs is a problem because of this.

  • My crosstool build created the libthread_db.so file, and I put it on the target.

  • My crosstool build created the gdb for my target, so it should have been linked against the same libraries that I run on the target.

  • If I run gdb on my host, against my test app, I get a backtrace of each running thread.

I suspect the problem with Breakpad is related to the problem with GDB, but I cannot substantiate this. The only commonality is lack of multithreaded debug.

There is some crucial difference between my host and target that stops me from being able to debug pthreads on the target.

Does anyone know what it is?

EDIT:

Denys Dmytriyenko from TI says:

Normally, GDB is not very picky and you can mix and match different versions of gdb and gdbserver. But, unfortunately, if you need to debug multi-threaded apps, there are some dependencies for specific APIs...

For example, this is one of the messages you may see if you didn't build GDB properly for the thread support:

dlopen failed on 'libthread_db.so.1' - /lib/libthread_db.so.1: undefined symbol: ps_lgetfpregs GDB will not be able to debug pthreads.

Note that this error is the same as the one that I get but he doesn't go in to detail about how to build GDB "properly".

and the GDB FAQ says:

(Q) GDB does not see any threads besides the one in which crash occurred; or SIGTRAP kills my program when I set a breakpoint.

(A) This frequently happen on Linux, especially on embedded targets. There are two common causes:

  • you are using glibc, and you have stripped libpthread.so.0

  • mismatch between libpthread.so.0 and libthread_db.so.1

GDB itself does not know how to decode "thread control blocks" maintained by glibc and considered to be glibc private implementation detail. It uses libthread_db.so.1 (part of glibc) to help it do so. Therefore, libthread_db.so.1 and libpthread.so.0 must match in version and compilation flags. In addition, libthread_db.so.1 requires certain non-global symbols to be present in libpthread.so.0.

Solution: use strip --strip-debug libpthread.so.0 instead of strip libpthread.so.0.

I tried a non-stripped libpthread.so.0 but it didn't make a difference. I will investigate any mismatch between pthread and thread_db.

解决方案

This:

dlopen failed on 'libthread_db.so.1' - /lib/libthread_db.so.1: undefined symbol: ps_lgetfpregs
GDB will not be able to debug pthreads.

means that the libthread_db.so.1 library was not able to find the symbol ps_lgetfpregs in gdb.

Why?

Because I built gdb using Crosstoolg-NG with the "Build a static native gdb" option and this adds the -static option to gcc.

The native gdb is built with the -rdynamic option and this populates the .dynsym symbol table in the ELF file with all symbols, even unused ones. libread_db uses this symbol table to find ps_lgetfpregs from gdb.

But -static strips the .dynsym table from the ELF file.

At this point there are two options:

  1. Don't build a static native gdb if you want to debug threads.
  2. Build a static gdb and a static libthread_db (not tested)

Edit:

By the way, this does not explain why Breakpad in unable to debug multithreaded applications on my target.

这篇关于我需要调试pthread?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆