进入共享库的条件应该在 gdb 中工作？

Question

有很多问题与特定错误有关，为什么无法使用 gdb 进入共享库。他们都没有提供关于如何确认原因所在的系统答案。这个问题是关于诊断设置的方法。

设置示例

ma​​in.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");
}

将所有文件放在同一目录中。

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

获取错误

$ 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 没有进入函数内部

必要但不充分的检查

二进制文件中的调试符号

$ 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_str

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.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，没有 .gdbinit。)。

可能相关:17.04 amd64 上的 gcc 已经构建(由 Canonical)默认生成 pie 可执行文件。

问题

构建 gcc 的标志会干扰调试吗？您如何确定问题是否出在您的 gcc 上？

Answer 1

你的问题是你自己强加的:不要这样做:set step-mode on，step 将按你预期的方式工作。

来自 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.

您对上面的相反感兴趣 -- 您想要单步执行 print_from_lib 函数并避免在 PLT 跳转内停止 stub 和动态加载器的符号解析函数。