有很多与特定错误相关的问题，为什么使用gdb进入共享库不起作用。他们都没有提供有关如何确定原因的系统答案。这个问题是关于诊断设置的方法。
设置示例main.c
#include #includemyshared.h int main（void） { int a = 3; print_from_lib（）; 返回0; }myshared.h
void print_from_lib（）;myshared.c
#include< stdio.h> void print_from_lib（） { printf（从共享库打印\）; }将所有文件放在同一个目录中。
export LIBRARY_PATH = $ PWD：$ LIBRARY_PATH export LD_LIBRARY_PATH = $ PWD：$ LD_LIBRARY_PATH gcc -ggdb -c -Wall -Werror -fpic myshared.c -o myshared-ggdb.o gcc -ggdb -shared -o libmyshared-ggdb.so myshared -ggdb.o gcc -ggdb main.c -lmyshared -ggdb -o app -ggdb获取错误 <$ p $ GDB启动文本$ b $ gdb启动文本$ b $ gb启动文本$ b $ $ gdb ./app-ggdb GNU gdb（Ubuntu 7.12.50.20170314-0ubuntu1）7.12.50.20170314-git ... ### GDB启动文本从app-ggdb中读取符号...完成。 （gdb）break 7 0x78f处的断点1：file main.c，第7行。（gdb）run 启动程序：/ home / user / share-lib-例如/ app-ggdb 断点1，main.c中的main（）：7 7 print_from_lib（）; （gdb）s 从共享库打印 8返回0;
gdb不会进入函数中 必要但没有足够的检查 二进制文件中的调试符号
$ objdump --syms libmyshared-ggdb.so | grep debug 0000000000000000 ld .debug_aranges 0000000000000000 .debug_aranges 0000000000000000 ld .debug_info 0000000000000000 .debug_info 0000000000000000 ld .debug_abbrev 0000000000000000 .debug_abbrev 0000000000000000 ld .debug_line 0000000000000000 .debug_line 0000000000000000 ld .debug_str 0000000000000000 .debug_str由gdb识别的符号
$ gdb ./app-ggdb ... ### GDB启动文本从app-ggdb中读取符号...完成。 （gdb）break 7 0x78f处的断点1：file main.c，第7行。（gdb）run 启动程序：/ home / user / share-lib-例如/ app-ggdb 断点1，main.c中的main（）：7 7 print_from_lib（）; （gdb）（gdb）info sharedlibrary 从To Syms读共享对象库 0x00007ffff7dd7aa0 0x00007ffff7df55c0是/lib64/ld-linux-x86-64.so.2 0x00007ffff7bd5580 0x00007ffff7bd5693是/home/user/share-lib-example/libmyshared-ggdb.so 0x00007ffff782d9c0 0x00007ffff797ed43是/lib/x86_64-linux-gnu/libc.so.6确认.gdbinit不是原因
〜/ .gdbinit 包含启动gdb时自动执行的命令。 ref。
使用 -nx 标志运行gdb可以排除 .gdbinit 作为问题的根源。 问题
正在寻找建议来完成的列表，但必要但不充分支票。
当前版本[Mark Plotnick更新]
此步骤错误在Ubuntu 17.04 amd64上具有64位和32位可执行文件和库的可重复性。
该错误在Ubuntu 17.04上无法重现I386。 （gcc 6.3.0-12ubuntu2，gdb 7.12.50和8.0，no .gdbinit。）。
可能相关：17.04 amd64上的gcc已经建立（由Canonical创建）默认情况下生成馅饼可执行文件。
问题
构建时会干扰调试？如何确定你的gcc是否是原因？
解决方案你的问题是自我强加的：不要这样做： code>在上设置步进模式， step 将按照您的预期工作。
从GDB 手册
设置步进模式设置的步进模式设置步进模式on命令会导致step命令在不包含调试行信息的函数的第一个指令处停止，而不是跨越它。 这对于您可能有兴趣检查没有符号信息并且不希望 GDB自动跳过此函数的函数的指令的机器很有用。您对上述的相反感兴趣 - 想要步骤到 print_from_lib 函数，避免停在PLT跳转存根和动态加载器的符号解析函数中。
There are many questions related to specific errors why stepping into a shared library with gdb isn't working. None of them provide a systematic answer on how to confirm where the the cause is. This questions is about the ways to diagnose the setup.
Setup examplemain.c
#include <stdio.h> #include "myshared.h" int main(void) { int a = 3; print_from_lib(); return 0; }myshared.h
void print_from_lib();myshared.c
#include <stdio.h> void print_from_lib() { printf("Printed from shared library\n"); }Place all the files in the same directory.
export LIBRARY_PATH=$PWD:$LIBRARY_PATH export LD_LIBRARY_PATH=$PWD:$LD_LIBRARY_PATH gcc -ggdb -c -Wall -Werror -fpic myshared.c -o myshared-ggdb.o gcc -ggdb -shared -o libmyshared-ggdb.so myshared-ggdb.o gcc -ggdb main.c -lmyshared-ggdb -o app-ggdbGetting the error
$ gdb ./app-ggdb GNU gdb (Ubuntu 7.12.50.20170314-0ubuntu1) 7.12.50.20170314-git ...### GDB STARTING TEXT Reading symbols from app-ggdb...done. (gdb) break 7 Breakpoint 1 at 0x78f: file main.c, line 7. (gdb) run Starting program: /home/user/share-lib-example/app-ggdb Breakpoint 1, main () at main.c:7 7 print_from_lib(); (gdb) s Printed from shared library 8 return 0;gdb is not stepping inside of the function
Necessary but not sufficient checks Debug symbols in the binaries $ objdump --syms libmyshared-ggdb.so | grep debug 0000000000000000 l d .debug_aranges 0000000000000000 .debug_aranges 0000000000000000 l d .debug_info 0000000000000000 .debug_info 0000000000000000 l d .debug_abbrev 0000000000000000 .debug_abbrev 0000000000000000 l d .debug_line 0000000000000000 .debug_line 0000000000000000 l d .debug_str 0000000000000000 .debug_strSymbols recognized by gdb
$ gdb ./app-ggdb ...### GDB STARTING TEXT Reading symbols from app-ggdb...done. (gdb) break 7 Breakpoint 1 at 0x78f: file main.c, line 7. (gdb) run Starting program: /home/user/share-lib-example/app-ggdb Breakpoint 1, main () at main.c:7 7 print_from_lib(); (gdb)(gdb) info sharedlibrary From To Syms Read Shared Object Library 0x00007ffff7dd7aa0 0x00007ffff7df55c0 Yes /lib64/ld-linux-x86-64.so.2 0x00007ffff7bd5580 0x00007ffff7bd5693 Yes /home/user/share-lib-example/libmyshared-ggdb.so 0x00007ffff782d9c0 0x00007ffff797ed43 Yes /lib/x86_64-linux-gnu/libc.so.6Confirm .gdbinit isn't the cause
~/.gdbinit contains commands automatically executed upon starting gdb. ref.
Running gdb with the -nx flags can exclude .gdbinit as the source of the problem.
QuestionAm looking for suggestions to complete the list of Necessary but not sufficient checks.
Current issue [Update from Mark Plotnick]
This step bug is reproducible on Ubuntu 17.04 amd64 with both a 64- and 32-bit executable and library.
The bug isn't reproducible on Ubuntu 17.04 i386. (gcc 6.3.0-12ubuntu2, gdb 7.12.50 and 8.0, no .gdbinit.).
Possibly relevant: gcc on 17.04 amd64 has been built (by Canonical) to generate pie executables by default.
Question
Can flags with which gcc was build with interfere with debugging? How can you identify if your gcc is the cause?
解决方案Your problem is self-imposed: don't do this: set step-mode on, and step will work as you expect.
From the GDB manual:
set step-mode set step-mode on The set step-mode on command causes the step command to stop at the first instruction of a function which contains no debug line information rather than stepping over it. This is useful in cases where you may be interested in inspecting the machine instructions of a function which has no symbolic info and do not want GDB to automatically skip over this function.You are interested in the opposite of the above -- you want to step into the print_from_lib function and avoid stopping inside the PLT jump stub and the dynamic loader's symbol resolution function.
更多推荐
步入共享库的条件应该在gdb中工作？
发布评论