外部程序中引起 SIGSEGV 的指令地址
我想获取导致外部程序发生 SIGSEGV 的指令地址。我尝试使用 ptrace 来实现此目的，但我从内核空间获取 EIP（可能是默认信号处理程序？）。 GDB如何获取正确的EIP？
有没有办法让 GDB 使用一些 API 提供这些信息？
编辑： 我没有该程序的源代码，只有二进制可执行文件。我需要自动化，所以我不能简单地使用GDB中的“运行”、“信息寄存器”。我想在我自己的迷你调试器中实现“信息寄存器”:)
I want to get address of instruction that causes external program to SIGSEGV. I tried using ptrace for this, but I'm getting EIP from kernel space (probably default signal handler?). How GDB is able to get the correct EIP?
Is there a way to make GDB provide this information using some API?
edit:
I don't have sources of the program, only binary executable. I need automation, so I can't simply use "run", "info registers" in GDB. I want to implement "info registers" in my own mini-debugger :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可以使用 ptrace 附加到进程。我在 Linux Gazette 上找到了一篇文章。
看来您需要 PTRACE_GETREGS 作为寄存器。您将需要查看一些示例代码（例如 strace），以了解它如何管理信号处理等。通过阅读文档，我发现被跟踪的子进程将在每个信号处停止，并且跟踪父进程必须
wait()来自子进程的信号，然后命令它继续使用 PTRACE_CONT。You can attach to a process using ptrace. I found an article at Linux Gazette.
It looks like you will want PTRACE_GETREGS for the registers. You will want to look at some example code like strace to see how it manages signal handling and such. It looks to me from reading the documentation that the traced child will stop at every signal and the tracing parent must
wait()for the signal from the child then command it to continue using PTRACE_CONT.使用
-g编译程序，运行gdb，输入run，就会出现错误。之后使用info registers并查看rip寄存器。您可以使用
objectdump -D获取有关该位置代码的更多信息。Compile your program with
-g, rungdb <your_app>, typerunand the error will occur. After that useinfo registersand look in theripregister.You can use
objectdump -D <your_app>to get some more information about the code at that position.您可以在运行外部程序之前使用
ulimit -c unlimited启用核心转储。然后，您可以在崩溃后使用 gdb /path/to/program corefile 检查核心转储文件，
因为它是二进制的并且未使用调试选项进行编译，您必须在寄存器和机器代码级别查看详细信息。
You can enable core dumps with
ulimit -c unlimitedbefore running your external program.Then you can examine the core dump file after a crash using
gdb /path/to/program corefileBecause it is binary and not compiled with debugging options you will have to view details at the register and machine code level.
尝试制作核心转储，然后使用 gdb 进行分析。如果您的意思是让 gdb 通过“自动化”一键运行所有命令，gdb 也可以这样做。将命令键入文件并查看手册的帮助用户定义部分，gdb 可以处理预设命令。
Try making a core dump, then analyse it with gdb. If you meant you wanted to make gdb run all your commands at one touch of a key by 'automate', gdb ca do that too. Type your commands into a file and look into the help user-defined section of manuals, gdb can handle canned commands.