GDB 不会在 SIGSEGV 上中断
我正在尝试从我的 x86 机器上调试 ARM 处理器的应用程序。我遵循了之前某人的指示来设置开发环境。我有一个针对 ARM 处理器交叉编译的 gdbserver 版本，似乎允许我通过我的盒子上的 ARM 感知 gdb 连接到它。
我期望当我附加的 gdb 进程崩溃（来自 SIGSEGV 或类似）时，它会中断，以便我可以检查调用堆栈。
这是一个糟糕的假设吗？我是 ARM 世界和交叉编译的新手，是否有一个好的资源可以帮助我开始处理我所缺少的东西？
I'm trying to debug an application for an ARM processor from my x86 box. I some followed instructions from someone that came before on getting a development environment setup. I've got a version of gdbserver that has been cross-compiled for the ARM processor and appears to allow me to connect to it via my ARM-aware gdb on my box.
I'm expecting that when the process I've got gdb attached to crashes (from a SIGSEGV or similar) it will break so that I can check out the call stack.
Is that a poor assumption? I'm new to the ARM world and cross-compiling things, is there possibly a good resource to get started on this stuff that I'm missing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这取决于目标系统（使用 ARM 处理器的系统）。一些嵌入式系统检测到无效的内存访问（例如取消引用NULL），但会以无条件的、不可捕获的系统终止做出反应（我已经在这样的系统上进行了开发）。目标系统运行什么类型的操作系统？
It depends on the target system (the one which uses an ARM processor). Some embedded systems detect invalid memory accesses (e.g. dereferencing NULL) but react with unconditional, uncatchable system termination (I have done development on such a system). What kind of OS is the target system running ?
所以我假设 gdb 客户端能够连接到 gdbserver 并且您能够在正在运行的进程上放置断点，对吗？
如果上述所有步骤都成功，那么您应该将断点放在崩溃的指令之前，假设您不知道它在哪里崩溃，那么我会说一旦应用程序崩溃，就会生成核心，从董事会。然后使用 -g 选项（如果二进制文件被剥离）再次使用调试选项编译源代码，并对核心进行离线分析。类似下面的
gdb binary-name core_file
然后一旦你得到 gdb 提示符，给出下面的命令
gdb thread apply all bt
上面的命令将为你提供所有线程的完整回溯，记住二进制文件不应该被删除，并且所有的正确路径源代码和共享库应该可用。
您可以在 gdb 提示符上使用以下命令在线程之间切换
gdb thread thread_number
如果核心文件未在板上生成，则在执行应用程序之前在板上尝试以下命令
ulimit -c unlimited
So i assume that the gdb client is able to connect to gdbserver and you are able to put the break point on the running process right?
If all the above steps are successful then you should put the break point before the instruction which crashes, lets say if you dont know where is it crashing then i would say once the application is crashed, the core will be generated, take that core from the board. Then compile the source code again with debug option using -g option(if binaries are stripped) and do the offline ananlysis of core. something like below
gdb binary-name core_file
Then once you get gdb prompt ,give below commands
gdb thread apply all bt
The above command will give you the complete backtrace of all the threads, remember that binaries should not be stripped and the proper path of all the source code and shared lib should be available.
you can switch between threads using below command on gdb prompt
gdb thread thread_number
If the core file is not getting generated on the board then try below command on board before executing the application
ulimit -c unlimited